Aria / Role attributes on menu

I have the following HTML structure

<nav role="navigation" aria-label="Main menu">
  <ul class="lvl1" role="menubar" aria-hidden="false">
    <li class="fsNavParentPage" role="menuitem" aria-haspopup="true">
      <a href="#">Link 1</a>
      <div class="dropdown-wrapper">
        <ul class="lvl2" data-test="true" aria-hidden="false" role="menu">
          <li role="menuitem">
	    <a href="#">Child 1</a>

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?

This menu is based off of -

Why is the data-test in there? It’s added via Javascript, and I am wondering if I can remove that? Doesn’t seem to do anything.

AFAIK “data-whatever” attributes aren’t used by browsers.

In this case it looks to be a left-over from working up a tab index problem

// Set tabIndex to -1 so that top_level_links can't receive focus until menu is open
	.attr({ 'aria-hidden': 'true', 'role': 'menu' })

I’m guessing you could safely remove it. On the other hand, I don’t see where leaving it would cause any problems either.

1 Like

Thanks! Just wanted a second voice to confirm that.

Does anyone have thoughts on this?

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.

See also

1 Like

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” ()

But do screen readers follow those semantic cues?

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.

Hmm, I did find this

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…

This is a recent article.

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.

1 Like

That page says at the top:

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:

1 Like

It says not to use it but if older screen readers would benefit due to it being older technology, do you think I should put it on?

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.