I have been tasked with going through the a11y project checklist.
(http://a11yproject.com/checklist.html) for those who aren't sure what that is.
I noticed that on our website, (www.adn.com) when you tab through the website, it goes through our entire left-rail menu, before making it to the article content.
Is there some way to manipulate the order in which our site is "Tabbed through" for keyboard only users?
New to the industry, currently am a Junior Dev. Apologies if this is a simple question.
what you are looking for is tabindex
w3schools example
W3Schools
Google
Microsoft
Reference: w3schools.com/tags/att_global_tabindex.asp
The problem you're having isn't a tabindex issue, as the tabindex is correct for the menu's position in the DOM. (also changing tabindexes to values beyond 0 or -1 can really screw up the expected tab order for an interface).
What is going on here is that the menu has been visually hidden, by positioning it off screen, but it has not been adequately hidden from keyboard users/screen readers.
You'll need to update the CSS of your menu, so that when it is positioned off screen, the id="slider-menu-nav-list" is set to display: none. Then when the menu button is activated, the #slider-menu-nav-list should be set to display: block;
Looking through the source code some more, you'll also have to change your Menu button into an actual <button> element, as it's currently keyboard inaccessible as a <div><span> combo, so there is currently no way for a keyboard users to actually open the menu. (not all keyboard users are blind, and it can be frustrating to not be able to see where your current keyboard focus is located).
Hope this helps!
Related
I've been trying to find an answer to this, but can't quite get a clear one. I'm using a MUI Select component in my app, and noticed that it the menu items are able to be navigated with up/down keys and selected with the enter key, but not able to go up/down with the tab key. Is this a best practice for accessibility, or is it not required? I also looked at this guideline, which seems like tabbing isn't required. Just want need some validation on this. Thank you!
If you mean the different options of a dropdown menu, no, they shouldn't be reachable with tab.
This is probably more a common convention or a recommandation than an absolute obligation, as far as I know.
It comes from native UI control/widget/component conventions on most operating systems that have been in use long time before the web.
The tab key is normally used to go from a control to the next.
But when you go through the different options of a dropdown menu, you stay on the same control.
So dropdown options don't have to, and even really shouldn't be reachable with the tab key.
The same answer applies on the different tabs of a tab control, or the items in a list of selectable items. Normally when navigating with tab, you should only reach the currently selected / active element. Another press on tab key moves to the next interactive control.
As mentioned before, the goal of TAB is typically to move from a specific input control.to another, not within it. Thus, the use of arrow keys and enter is fine. However as a screen reader user myself, I run across custom "selection" boxes that fail to work properly due to many reasons. even if keyboard navigation works as expected outside of a screen reader context. It isn't clear to me if you tried this under a screen reader.
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'm hoping to improve the experience for people using screen readers on a site that has a few menu levels with a lot of links (that might feel endless to people hearing every item).
Is there a way of instructing the screen reader what to say? Other than using a link and the SR reading the text (which in this case wouldn't make much sense). I was thinking something like:
"Further filtering of events can be done in the following sub menu. If you do not wish to do so, please tab through the sub menu to the event listings."
I know this isn't ideal; - at the moment I'm trying to figure out how to allocate focus to an element without javascript/jquery so that the tabbing through isn't necessary - but for future reference (for example if an element needs further explanation that isn't a link with text) this would be good to know.
I already have a Skip Navigation link on the page, but that is for the main menu.
Multiple skip links can be used
You could create a hidden link before the menu that allows you to skip it, if that's what you mean. When a user tabs onto it, they would hear your instruction and by selecting it they could bypass the menu.
More information on the WebAIM site: http://webaim.org/techniques/skipnav/
Highlights:
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.
Probably the most accessible method for visually hiding skip links is
to hide them off screen, then cause them to be positioned on screen
when they receive keyboard focus.
Skip links or other in-page links can also be used to allow users to
jump to or jump over page content. For example, the Table of Contents
at the top of this page includes in-page links to facilitate
navigation to page areas. A "skip" link could also be used to allow
the user to quickly bypass confusing or potentially inaccessible
content, such as ASCII art, complex tables, etc.
The Open Ajax Alliance Accessibility Examples site might help: http://www.oaa-accessibility.org/example/25/
It is difficult to tell from your description whether this is applicable to your situation. If it is then the example site provides a great amount of implementation guidance for incorporating ARIA into your solution.
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.