ARIA roles can remove their children’s semantics

I've learned something new about ARIA today!

You probably know the first rule of ARIA:

If you can use a native HTML element or attribute with the semantics and behavior you require already built in, instead of repurposing an element and adding an ARIA role, state, or property to make it accessible, then do so.

Unfortunately, many people slap ARIA attributes on elements without really understanding what they're doing. Adding role="menu" to navigation lists is one example that I see very often.

What's supposed to be a menu? Here's the ARIA spec:

A menu is a container, generally rendered as a popup or overlay, for a set of menu items that can be invoked to perform an action or function.

Making a list of navigation entries a menu isn't a good idea because a menu is supposed to include menu items that invoke actions or functions. However, that's not all.

Today I learned that adding ARIA attributes to elements can also change the semantics of the included elements. Here's the role="menu" example for a ul case.

<ul>
  <li>Item 1</li>
  <li>Item 2</li>
  <li>Item 3</li>
</ul>

A "normal" list might be announced by a screen reader as "List (3 items)". It's helpful to know how many elements are in the list, right? A menu, though, must include menu items. And if you're not planning to also add elements with role="menuitem" to the menu, it'll be empty.

I quickly tested Chrome with VoiceOver on this CodePen:

• A normal list is announced as "List (3 items)".
• A list with role="menu" without included menuitems isn't announced at all. The list entries are read out loud.
• A list with role="menu" with included menuitems is announced as "Menu (3 items)".

Incorrect role="menu" usage can not only be confusing but might remove the list item count and nuke the item semantics.

Don't mess with ARIA unless you know what you're doing.

Check this post if you want to dive deeper into ARIA and what other roles affect their children semantics.