• Success Criterion 4.1.2
  • Conformance level A

ARIA Role Assigned That Doesn’t Match the Control’s Behavior

4.1.2 — Name, Role, Value

Scenario

Setting

A budget airline's flight search results

What’s wrong

Wrong roles: role="button" on real links changing announced behavior falsely — role="menu" on ordinary nav breaking arrow-key expectations.

Example 

<nav role="menu">
  <a role="menuitem" href="/flights?sort=price">Sort by price</a>
  <a role="menuitem" href="/flights?sort=duration">Sort by duration</a>
</nav>
<!-- role="menu" tells assistive tech to expect arrow-key navigation and Escape-to-close behavior
     that this plain link list never implements -->

Why it matters

A screen reader user pressing arrow keys inside what's announced as a menu gets no response, since it's really just page links.

How to test

Inspect the assigned ARIA role against the control's actual behavior: a role that doesn't match what the control does (e.g., role="menu" on plain navigation) fails.

How to fix

Reserve role="menu" for application-style menus with real arrow-key and Escape handling; plain navigation needs no role.

<nav aria-label="Sort flight results">
  <a href="/flights?sort=price">Sort by price</a>
  <a href="/flights?sort=duration">Sort by duration</a>
</nav>

Outcome

A traveler tabs through the sort links exactly the way a screen reader user expects links to behave.

Who is affected

Screen reader users sorting flight results hit broken keyboard expectations set by the mismatched menu role.

Learn more

Related scenarios