UA: Mozilla Firefox 28.0;
AT: JAWS 14.0.1534 and NVDA 2014.1;
OS: MS Windows 7 Professional SP1
Given the following simple ARIA-enhanced menu widget, why is the associated 'Where to go' label never read? It's been my understanding that labels associated with focusable elements should be announced when focus is received. Instead, only the menu item's text is read.
<div role="application">
<ul id="main-menu" role="menu" aria-label="Where to go" aria-activedescendant="item-1" tabindex="0">
<li id="item-1" role="menuitem">First page</li>
<li id="item-2" role="menuitem">Second page</li>
<li id="item-3" role="menuitem">Third page</li>
</ul>
</div>
Is it some kind of "optimization" as to prevent excessive information to be read to the user everytime the menu received focus? Like, the contents of the "menuitem" would be prioritized over the labelling of the containing menu widget. Of course, this is just a wild guess. Does anybody have more details that could help clarify the above situation?
A related question based on the same code sample: I've found out that doing away with the containing div (the one with the role="application" attribute) changes absolutely nothing regarding the behavior of the widget (there's Javascript code for controlling keyboard interaction and updating the UL's aria-activedescendant attribute). When do you actually need a container with role="application"?
Based on the example, it doesn't look like something that should be a menu.
The menu role is intended for application style menus which pop-up sub-menus. See this menubar example.
Upon tabbing to the menu, you then use arrow keys to navigate, not tab.
What you've got (so far at least) is simple navigation, and on a website the most appropriate mechanism is standard links.
<nav aria-label="Where to go">
<ul id="main-menu">
<li>First page</li>
<li>Second page</li>
<li>Third page</li>
</ul>
</nav>
The aria-label may or may not be read out by a screenreader (in a brief test NVDA did not, VoiceOver did), if that is important hide an off-screen heading above the menu. However, that label is used if the user navigates by "landmark".
If you do go for a full menu, I'd try the accessible Adobe mega-menu.
Related
I use jquery-ui tabs. Sample code:
<ul role="tablist">
<li role="tab"><a class="label" href="#tabs-1" aria-label="Description tab">Description</a></li>
<li role="tab"><a class="label" href="#tabs-2" aria-label="Reviews tab">Reviews</a></li>
<li role="tab"><a class="label" href="#tabs-3" aria-label="Credits tab">Credits</a></li>
<li role="tab"><a class="label" href="#tabs-4" aria-label="Cataloging tab">Cataloging</a></li>
</ul>
The axe-core DevTools accessibility checker flags a "serious" problem with this code: "Interactive controls must not be nested", with the explanation "Interactive control elements must not have focusable descendants" and referencing guideline WCAG 4.1.2.
The problem, as I understand it, is that there is a link inside the listitem. From a Github discussion for axe-core (https://github.com/dequelabs/axe-core/issues/601), the clickable link within the list item causes issues with screen readers.
But this seems like a standard use of the jquery-ui tab widget. How I do change the tabs widget code to make it accessible?
The items within <ul role="tablist"> will have tabindex="0" etc. added to them in order to make them focusable (the actual li, not the link) and then the anchor should have tabindex="-1" added to it.
The idea is that the link is a fallback for if JS fails, this is why it is included in the first place and isn't just plain text.
However this does indeed cause nesting of interactive elements as you now have tabindex="0" on the list item (making it "interactive" / focusable) and then a link within it.
They add tabindex="-1" to the link to remove it from the focus order, but some screen reader / browser combos will still pick this link up and this is why it is flagged.
So there is a workaround but you will need to implement it yourself.
First, add role="none presentation" to the link:
<li role="tab"><a class="label" href="#tabs-1" role="none presentation">Description</a></li>
What this does is signal that this anchor should be treated like a <div> or a <span> as far as assistive technology is concerned (it removes all semantic meaning).
Secondly, (but you would have to check it works with jQuery-UI) would be to remove the href attribute from the link via JS (so it is only removed once the Tab component has initialised).
You should end up with the following if you inspect the elements after doing this (ignoring any classes added etc.):
<li role="tab"><a class="label" role="none presentation">Description</a></li>
This will stop it being a focusable item if JS works and loads correctly, but will fall back gracefully if JS fails to load.
Also notice I removed your aria-label as the fact you are using a role="tab" already tells a screen reader that it is a tab so your label was not needed.
So in summary:
add role="none presentation" to the links within the <li>
remove the href attribute from the links via JavaScript.
remove the aria-label (not related to the problem)
This should make the tabs as accessible as possible within jQuery-UI, but there may be other problems with it so I can't say whether it is accessible or not!
I'm working on a menu with links, the structure is ul > li > a tag with href, and the links are not receiving focus on tabbing through the menu. As far as I'm aware the default behaviour of an a tag with a valid href is to receive keyboard focus on tab. Is this an OS/browser issue? I'm on Mac running Catalina and browsing in Chrome.
<ul class="collapse" id="footerLinksHelp">
<li class="footer-links__item">
Delivery
</li>
<li class="footer-links__item">
Returns
</li>
<li class="footer-links__item">
Check my Order
</li>
<li class="footer-links__item">
Terms & Conditions
</li>
<li class="footer-links__item">
<a href="https://customer-support.com" rel="noopener" target="_blank">Customer
Support</a>
</li>
</ul>
I've googled this and read through accessibility docs but can't figure out why the a tags are not receiving any keyboard focus. This is an accessibility requirement identified by testing.
Try adding tabindex=0 attribute to your link (anchor tag). Your browser can cause issues like this sometimes but that can't be determined from the above snippet.
in my site i have menu and sub menu
my problem when i focus by tab to the menu, the menu opened like i hovered the menu by mouse.
but when i continued to the sub menu elements with tab the menu closed.
how can i keep the menu open if some of sub element is focused.
of course i can do it via javascript, but i want to know if i can do it with css only.
here is example (try go to links with 'tab' )
li.main{
float:left;
width:200px;
}
li .sub{
display:none;
}
li:hover .sub{
display:block
}
li.main:focus .sub{
display:block
}
<ul>
<li class="main" tabindex="0">
First menu
<div class='sub'>
<ul>
<li>First Link </li>
<li>Second Link </li>
</ul>
</div>
</li> <li class="main" tabindex="0">
Second menu
<div class='sub'>
<ul>
<li>Third Link </li>
<li>Forth Link </li>
</ul>
</div>
</li>
</ul>
With the current possibilities of CSS, you can't, as it was discussed in a lot of questions before (see accessible css dropdown menu for instance).
First of all, you can't use "display:none" in such approach because the link can't be accessed using the next link shortcut (tab key in most of the browsers implementation).
Solutions which work will imply solutions like positioning out of screen. It will restrict the view on screen to the current link as there is no parent() selector in CSS, or you might use a trick like in the above thread (which will work in some browsers and limit the width of the dropdown part).
But no matter the solution, it will not resolve the main problem : a dropdown menu is not the best way to achieve accessibility.
For instance, people with disabilities using eye tracking software will never benefit of a dropdown menu. Neither will people using tablet.
It is always something difficult to use, difficult to understand : What if I click on the category link? Does it open the category main page, or does it open the submenu?
If you really want an accessible menu, do not use a dropdown menu
I'm doing some code clean up / validation in a web site, and have run into an issue. The site have a main menu (menubar) where the current page should be indicated.
The menu structure as is:
<nav role="navigation">
<ul role="menubar">
<li role="menuitem" aria-selected="true">
Current page
</li>
<li role="menuitem">
Another page
</li>
</ul>
</nav>
According to the WAI-ARIA spec, the state aria-selected is not allowed on the role menuitem: http://www.w3.org/TR/wai-aria/states_and_properties#aria-selected. Neither can I find any state for menuitem that seem to mark the menuitem as selected: http://www.w3.org/TR/wai-aria/roles#menuitem.
What would be the correct implementation of a selected menuitem/page in a menubar?
Update:
I found one answer suggesting to leave the anchor out on the current page in the menu, but not sure if that will give me what I want.
<li role="menuitem">Current page</li>
As laid out very nicely in the blog entry The Accessible Current Page Link Conundrum there seems to be an upcoming solution by introducing the attribute aria-current="true".
For now, you stay with
your finding of either leaving the anchor out on the current page menu item
or include an aria-described attribute, which is specified to attach descriptive information to one or more elements by referencing an ID. Example:
<nav role="navigation">
<ul>
<li>Home</li>
<li>About</li>
<li>Contact</li>
</ul>
<span id="a11y-desc-current">current page</span>
</nav>
Is there a way (or component i could use) to output a simple menu.
I just need it output as a list, like you would use for a simple superfish menu.
I've looked at the menu control and cssadapters (css friendly) which kind of works,
except there is a lot of styles and javascript output with the menu which is destroying the look.
If I can't find something that outputs a clean list, my next option is to craft some jquery to delete these styles. This is not my preferred option. If you have a better idea, please let me know.
Just something that looks like this:
<ul> Main Menu
<li> hi </li>
<li> second menu
<ul>
<li> in second menu </li>
<li> hi there </li>
</ul>
</li>
</ul>
Thanks.
You can use the Repeater server control. You are in control of all of the markup output to the screen.