Basically, for the .lvl2{} <ul>, should those attributes be on the dropdown-wrapper element since that’s what’s “hidden” technically? What’s the proper way to handle this?
// Set tabIndex to -1 so that top_level_links can't receive focus until menu is open
$(top_level_links).next('ul')
.attr('data-test','true')
.attr({ 'aria-hidden': 'true', 'role': 'menu' })
.find('a')
.attr('tabIndex',-1);
I’m guessing you could safely remove it. On the other hand, I don’t see where leaving it would cause any problems either.
The only thing I know for sure is that <nav> shouldn’t have a role attached to it.
aria-hidden — Hides an element from being read out by a screenreader. As different tabs are selected by the user, the value of this attribute on the different tabs is updated via JavaScript.
So it looks like aria-hidden should be on the .dropdown-wrapper{} element. I assume the role=“menu” should stay on the .lvl2{} element.
I don’t see anything about role=“navigation” in those links, @TechnoBear . Have I missed it? I haven’t found any sources about the role=“navigation” on the <nav> element.
There is this in the WAI-ARIA mozilla ink
Roles — These define what an element is or does. Many of these are so-called landmark roles, which largely duplicate the semantic value of HTML5 structural elements e.g. role=“navigation” ()
It’s in the first link above, about the <nav> element.
Permitted ARIA roles: None
I think it’s because its role is clearly defined, so adding role="navigation" would be redundant.
I seem to remember @Stomme_poes saying folk using assistive technology tend to be using older systems/browsers, as the software is too expensive to upgrade frequently. So how well they handle the HTML5 elements, I don’t know. Hopefully, she might be around to enlighten us.
It seems to advise you doing role=navigation on the element. Googling now to see how JAWS / other screen readers want you to handle aria roles…Thanks technobear. I missed that.
But it says
Note: When support for HTML5 improves there may be no need to continue to add the ARIA role=“navigation”.
Wish I had a screen reader to test whether it makes a difference. That was in 2014…
It seems that since screen readers are on older technology, whether or not it’s redundant, if this role even helps one or two screen reader devices, it’s worth it. So I think I’m going to keep it on just for the potential chance of it helping even one screen reader device.
This Wiki page is edited by participants of the WCAG Working Group. It does not necessarily represent consensus and it may have incorrect information or information that is not supported by other Working Group participants, WAI, or W3C. It may also have some very useful information.
The W3C specs for nav say very clearly not to use it:
