Summary: Real world example of the Broken ARIA menu Error.
You can review what this means technically and the impact inside of our Results dictionary. Today I am only looking at this from the perspective of a Broken ARIA menu Error found on a higher ed website from our Higher Ed in 4k project.
Example
On this admissions page there is a navigation bar to the left of the page content. This side navigation is a list with 6 items each having sub items. The ARIA role=”menu” is used on the sub menus.
HTML
<nav class="sidenav" role="navigation">
<ul class="">
<li class="dropdown">
<i class="fa fa-plus" aria-hidden="true" data-toggle="dropdown" aria-haspopup="true" aria-expanded="true"></i>
<a href="/explore-Our-Programs">Explore Our Programs</a>
<ul class="subnav dropdown-menu" role="menu">
<li class="subNOchildren">
<i class="fa fa-chevron-right" aria-hidden="true"></i>
<a href="/colleges-and-Degrees">Colleges and Degrees </a>
</li>
<!-- additional sub nav items go here -->
</ul>
</li>
<!-- additional top nav items go here -->
</ul>
</nav>WAVE has flagged this an a Broken ARIA menu because the menu uses role=”menu” and has no children with role=”menuitem”. An ARIA menu needs menu items.
Solution
The simple answer is remove role=”menu” from each sub navigation list. Yes, it is a navigation and you might even call it a menu but that isn’t want role=”menu” is for. Never use an ARIA menu for a website navigation element. There is quite a bit of work to do it right, the standard for an ARIA menu uses different keys to navigate, which you would then need to train your users on. Simpley don’t do it on a website navigation.
This website on a screen reader tells me it is a menu, which tells me I should be able to navigate with the arrow keys instead of the tab key as well as quite a few other interactions. It is confusing and not helpful. Accessibility has been decreased rather than increased.
Where does this ARIA come from if it doesn’t help or even hurts accessibility?
Copy and paste. Somewhere someone saw an incorrect example and copied it and pasted it or learned the incorrect example. The key to avoiding this is make sure you understand what the ARIA is doing or don’t add it. Any time you add ARIA, which is only for assistive technologies, make sure you test with a screen reader.
In this example there is other code that was pasted as well that doesn’t do anything. This navigation was never tested with even a keyboard, let alone a screen reader. I can’t even access the sub menus with anything but a mouse.
Updated html
<nav class="sidenav">
<ul class="">
<li class="dropdown">
<i class="fa fa-plus" aria-hidden="true"></i>
<a href="/explore-Our-Programs" aria-expanded="false">Explore Our Programs</a>
<ul class="subnav dropdown-menu">
<li class="subNOchildren">
<i class="fa fa-chevron-right" aria-hidden="true"></i>
<a href="/colleges-and-Degrees">Colleges and Degrees</a>
</li>
<!-- additional sub nav items go here -->
</ul>
</li>
<!-- additional top nav items go here -->
</ul>
</nav>First I removed the role=”menu” on the sub menu. The WAVE error is now gone, but there is still some more cleanup and other issues I fixed. I then removed the aria-haspopup=”true” from the <i> for a few reasons. It is on a non-interactible element that has aria-hidden=”true”, it is hidden to a screen reader and does nothing. The other reason is it is used to indicate an aria menu opens which we have removed.
I removed role=”navigation” from the <nav> element as it means the same thing as <nav> and is redundant. When <anv> first started being used it was a good fallback as browser support increased but isn’t needed anymore.
On the <i> I also removed the data-toggle=”dropdown” as it was on the wrong element and not doing anything. This isn’t something related to accessibility but is used by the Bootstrap framework and was copy and pasted in the wrong place. I moved the aria-expanded=”true” from the non interactible <i> to the <a> and changed it to be “false” by default. This was again something that was pasted in the wrong place with the wrong default value.
Keyboard navigable
The last step needed is to make sure that you can edit this with a keyboard and that the aria-expanded=”false” changes to “true” when the sub navigation expands. This website uses Bootstrap which supports this, all we have to do is follow the default Bootstrap example by adding a few classes. We can even remove the custom JavaScript used to show the sub navigation only on hover.
With these changes we have simplified our JavaScript and html, it is accessible to people with disabilities, and a better user experience for everyone now that it supports keyboard use.
Tired of testing pages one at a time?
Pope Tech can get you up and running with usable web accessibility data in just a few minutes.
Email Newsletter
Want to receive emails with accessibility content similar to this article?
If you subscribe, we will email you web accessibility insights or things we learn a few times a month. You can unsubscribe at any time.