I'm trying to test the accessibility of a web page.
I'm using Apple Voice Over as screen reader on my MacBook and if I use voice over key short cuts, everything's working fine.
I can use voice over shortcuts (Ctrl + option + arrow-keys) to go through all elements of the page.
But if I turn the voice over off and try to navigate the web page using just the tab key, it doesn't work properly.
Tabbing just considers elements such as header, links and buttons but it ignores normal text.
Is this normal?
Is this acceptable?
It is totally normal, and it is actually the expected behaviour.
It is also acceptable because focus is meant to let user interact with some elements in the DOM. Only interactive elements are meant to be focused, the rest will just be ignored from the focus cycle.
The screen reader allows focusing pretty much any content on a page, as long as it is not set to be ignored by the screen reader (using aria-hidden="true" for example), and its behaviour can't really be compared to the tab cycle.
Using tab on a web page simply allows cycling through elements considered being interactive (i.e. focusable).
Text elements such as span, paragraphs, and even headers are not considered as focusable unless they are explicitly configured to be so. For example, specifying the tabindex attribute is one straightforward way to make an element focusable.
HTML 5.1 - User Interaction - Focus describes the focus mechanism in-depth and is worth reading.
Note that aria-hidden and tabindex can be used to make elements being focusable using keyboard but not being processed by a screen reader, or the opposite.
Related
We are running a tool called Axe to check the validity and 508-compliance/accessibility of HTML pages.
This error comes up as a violation:
Elements should not have tabindex greater than zero
The app is structured with top links and a nav bar. If we don't put in a tabindex, the tabbing starts from those elements. The idea is to hit the form inputs directly when coming onto the page. Surely that makes sense and should be allowed (even for disabled users)? Then why is a legitimate use case getting flagged?
<input id="phone" name="phone" tabindex="5" placeholder="" class="input-block-level" type="text" value="222">
Having a tabindex greater than zero is allowed in HTML in spite of what AXE is saying.
However, the way that you're using tabindex is presenting information to sighted users that is essentially being made unavailable to non-sighted users because they can't tab to it.
A better way to approach this would be to use hidden "skip links".
The idea is simple enough: provide a link at the top of the page which jumps the user down to an anchor or target at the beginning of the main content.
https://webaim.org/techniques/skipnav/
For sighted users, it's nice to have the focus on the first actionable element, such as the search field on amazon.com (although they don't do that). But sighted users have the whole page to take in with a quick glance. They can see where the focus is (assuming you have a focus indicator, 2.4.7) relative to the rest of the page and will immediately know there are navigation elements before the focus location and more stuff to interact with after the focus location.
For low vision users that use a magnifier, their viewport will be shifted to include the element that has focus. Usually when a page loads, the focus goes to the first element in the DOM that can receive focus. That's typically a "home" logo in the upper left (for LTR languages). Because the viewport is in the upper left, the low vision user will know that they can drag their viewport to the right or down to explore more of the page. But if the initial focus is somewhere in the middle of the page, that can be disorienting. The user might not know where on the page they are. How far from the upper left has the viewport shifted? How far can they explore up or down, left or right?
For extremely low vision or visually-impaired or blind users, users that use screen readers, the disorientation is even more dramatic. Screen reading software has great navigation tools so it's easy to explore the various elements of the page, provided semantic html elements are being used such as <h2> or <table> or <ul>. You can navigate to headings using the 'H' key, tables via the 'T' key, and lists via the 'L' key. But again, screen reader users will expect the initial focus to be in the upper left. They can certainly orient themselves and figure out where they are on the page, but it does take some cognitive effort, similar to the screen magnifier user.
So how do you make a pleasant experience for all these types of users (among many other types of users too)?
As one answer notes, "skip links" are very handy. In accessibility terms, these are called "bypass blocks" (2.4.1). They allow the default focus to be in the upper left (or wherever the default focus goes) and when you tab, the focus moves to the "skip link", which is an in-page link that lets you jump to the main part of the page. This is great for keyboard-only users (which might be sighted or visually-impaired users), screen magnifier users, and screen reader users.
However, if you really want the focus to be on a particular element, if the element is an <input> or <button> element, you can use the autofocus attribute. For other natively focusable elements, such as an <a>, you can have javascript that runs on load to call focus() on the element.
It's not a WCAG violoation to have the initial focus somewhere on the page other than the first element, so you're ok putting it on your form, just do it in a way to reduce confusion for users that have limited sight or can't use a mouse.
For more information about tabindex, see "5.5 Keyboard Navigation Between Components (The Tab Sequence)". Note that for tabindex values greater than 0, it says:
"Authors are strongly advised NOT to use these values."
Is there a way to prevent an 'aria-live' element from being focused by a screen reader?
I'm developing a calendar and would like to notify user whenever the currently selected month is changed.
As others have said, keyboard focus does not have to move to the aria-live region. Any changes made to a live region will just be announced. The focus will not move.
However, if you are asking whether you can prevent the user from moving their screen reader focus to the element, no, you can't prevent that. As long as the element is part of the accessibility tree (a subset of the DOM), the user can navigate to that element and hear its contents.
The rules on whether a DOM element is part of the accessibility tree are spelled out pretty well in "5.1 General rules for exposing WAI-ARIA semantics". Specifically, in the "5.1.2 Including..." section, it says elements that have text will be included. I'm presuming your aria-live element has text because it's being announced as you change it. If you jump back up to the "5.1.1 Excluding..." section, you can prevent the element from being on the accessibility tree if you use aria-hidden="true", but if you do that, then the live changes won't be read.
If implemented correctly, aria-live region will never receive visual focus.
Make sure that the live region is present on the page initially, only then dynamically added/changed content will be announced. Live region of the page that gets announced whenever content changes but the focus doesn't shift to the live region.
After a decade long hiatus I am dipping my toes into web development again. It still seems a very confusing heap of constantly changing standards to me, making it unclear which browsers support what and what the best practices are.
Currently, I am focusing on using the new semantic elements of HTML5. I found out the ASP.NET Core default Bootstrap template does not use the <nav> element for the navigation bar and was therefore looking into how to apply it properly.
The default navbar template in Bootstrap does recommend to use <nav>. However, I am confused as to what the purpose is behind the aria-expanded attribute applied to it. After learning about the benefits it offers to screen readers (indicating whether the navigation bar is collapsed or not, in this instance when the screen size is small, i.e., for smartphones), I am still confused as to whether it should be there at all. (And whether or not aria-controls should be applied, which it isn't in the default bootstrap template.)
Let me explain:
Some of these aria attributes seem to be describing visual behavior. Does it even make sense to describe something to the non-sighted which they can not see?
With the <nav> and <main> semantic elements applied correctly, don't the screen readers have all the necessary information at hand already to quickly skip the navigation bar (equivalent of hiding it for the sighted)?
Wouldn't a better alternative be to just hide the navigation toggle mechanism to the non-sighted altogether? Here my question then would be, how to go about this. Can a button be hidden using role="presentation" and/or aria-hidden="true"?
Using the example you cite at https://getbootstrap.com/examples/navbar/, it needs aria-expanded.
In the larger viewport, the "dropdown" menu hides all the sub-items. They are not only hidden visually, but hidden to screen readers as well. The aria-expanded helps give the user context whether or not there is more available, and also gives some clue about where the subsequent tab-stops may take the user.
In the narrower viewport, where the navigation becomes a hamburger, this still applies. Doubly so since it also applies to the hamburger itself.
This context is important since aria-controls support is poop (to quote Heydon).
There are cases where every item in a menu is available via tabbing, even if visually not there. In that case aria-expanded is not so important, but aria-controls would have more value.
Separately, that menu needs better :focus highlighting for sighted keyboard users, and DOM sequence for the menu versus logo in the narrow viewport (through that is my opinion).
Some of these aria attributes seem to be describing visual behavior. Does it even make sense to describe something to the non-sighted which they can not see?
That question should be the first to appear in any ARIA tutorial.
With the <nav> and <main> semantic elements applied correctly, don't the screen readers have all the necessary information at hand already to quickly skip the navigation bar (equivalent of hiding it for the sighted)?
And this one the second.
Edit: When I read those questions, I thought "that guy has already understood everything". ARIA tutorials rarely answer those questions because they are context dependent, but asking those questions must be the first step before using ARIA. Eg. image carousels are for blind people a very different user experience. Giving an aria-controls attribute to the "previous" button does not give more intelligence to a system based on visual effects. ARIA is not a miraculous panacea.
ARIA may be seen as a kind of magic potion for people wanting to make accessible something which is not accessible. In many cases it will be used ill-advisedly.
The aria-expanded can give a good user experience for screenreaders, informing whether or not an element can be opened to show more elements (for instance inside a dropdown menu).
You can't apply the aria-expanded directly on a nav element because it has to be set on an interactive element (like a button) to inform that this controls the visibility of another element inside the same container (which can be a nav).
The better alternative I can see is not hiding anything to also help people not using screenreaders. Instead of collapsing a navigation bar at small screen resolutions, it's perfectly possible to:
always show it
display a persistent menu icon to jump to the menu bar (or temporarily displaying it inside the viewport)
This has the benefit to enable the possibility to scroll to the menu bar (for people not understanding what that icon with three parallel lines may indicate) and let screenreaders users list all the internal links.
Of course, things are very different if you conceive a web application rather than a simple web site, and ARIA might be more useful in that context.
I have a page which I am supposed to make accessible without too many changes.
One combo box in the page is coded so that on clicking upon an input box, the contents of a div are copied into an iframe element in the same page, and that iframe is made visible below the input box.
I added aria-live to the container iframe, and Jaws would read the iframe that forms the drop down whenever it came up, but how do i link up the two such that Jaws focus can be shifted to the iframe whenever it is made visible and not just reading it out as a dynamic update?
I'm having a hard time understanding exactly how the UI is supposed to work based on your description. However, I can tell you that JAWS does not support aria-owns.
If you consult Freedom Scientific's documentation page, you'll find a Word document laying out JAWS' support for ARIA. It does not list aria-owns.
I am currently attempting to make my application be more user friendly to those with difficulty seeing. As one would expect, I am using JAWS to test my application. Most of the issues I have run in were relatively easy to fix, except I am stumped on one.
In my application, I have advertisements injected via an iframe and I want JAWS to ignore them, but I still want them to display (display:none is out of the question). Is there any way to have JAWS completely ignore an element and all of its children?
I saw a few posts leading towards speak:none, but that does not work. It does seems to ignore the parent div, but it will instead reads the content of the iframe child.
Any tips would be greatly appreciated.
Thank you.
Good for you for testing your web application for accessibility.
JAWS already has the feature built-in to ignore ads by temporarily or permanently ignoring inline iframes.
Testing that your site works nicely with that feature toggled should represent the typical experience for a JAWS user.
Banner Ads
If you want JAWS to temporarily ignore banner ads on a page, do the following:
Press INSERT+V.
Press I until you select "Inline Frames Show - On."
Press the SPACEBAR to choose "Inline Frames Show - Off."
Press ENTER.
To have JAWS permanently ignore all inline frames, including banner ads that you might encounter:
In Internet Explorer, press INSERT+F2.
Select Settings Center, and press ENTER.
Focus is in the Search edit box. Type in "ignore inline" without the quotes.
Press DOWN ARROW to move to Ignore Inline Frames in the filtered results of the tree view in Settings Center.
Press SPACEBAR to check or uncheck the check box.
Press TAB to move to the OK button and activate it with the SPACEBAR. The changes are made and saved. Settings Center closes.
http://www.freedomscientific.com/Training/Surfs-up/difficult_pages.htm
The other points mentioned on the above link will give you a good idea of additional bad practices to avoid.
Give the ARIA attribute aria-hidden="true" to the outer div of the iframe. This should ideally hide the the content from JAWS.
Give the aria attribute role="presentation" to any element you want ignored. Jaws will not read them.