Icon Button Menus: When ARIA Patterns Break Navigation

When the W3C published WCAG 2.1 in 2018, the guidance on Name, Role, Value (opens in new window) wasn't new — it had existed since WCAG 2.0 in 2008. A decade of clear guidance, and icon button menus remain among the most consistently broken patterns on the web. The hamburger menu, that three-line icon now ubiquitous on mobile and responsive layouts, is deceptively simple to build and surprisingly easy to build wrong.

An automated analysis of Bug 38: Icon Button — Menu (opens in new window) surfaces a pattern worth examining closely. The page tests three specific interaction patterns — an unlabeled hamburger menu, a menu with no state announcement, and menu items without proper role structure. The static analysis identified two structural violations that compound the interactive failures already documented in the page's own bug descriptions. Together, they illustrate something our research on automated testing methodology makes clear: automated tools catch the skeleton of a problem, not the full body of it.

The Finding

The automated analysis of this test page (opens in new window) identified two WCAG 2.1 violations:

Issue 1: No <nav> landmark found Violates WCAG 1.3.1 Info and Relationships (opens in new window) (Level A). Navigation menus are meaningful structural elements. When they exist without a <nav> landmark, that meaning is conveyed visually but not programmatically.

Issue 2: No <header>/banner landmark found Also violates WCAG 1.3.1 Info and Relationships (opens in new window) (Level A). The banner landmark (<header> at the top level, or role="banner") identifies the page header region. Its absence leaves screen reader users without a reliable way to orient themselves.

The page's own documented bugs add three ARIA-layer failures on top of these structural gaps:

• No aria-label on the hamburger button (☰)
• No aria-expanded state on the menu toggle
• No role="menu" / role="menuitem" on the menu structure itself

The static analysis also confirmed five passing checks, including that buttons carrying emoji characters (☰, 🔘, ⚙️) do have accessible names — though the mechanism providing those names matters, and that's where the documented bugs begin.

Problematic Code Pattern

<!-- Bug: No aria-label on Menu Button -->
<button>☰</button>

<!-- Bug: Menu State Not Announced -->
<button>🔘</button>
<ul>
  <li>Dashboard</li>
  <li>Settings</li>
  <li>Logout</li>
</ul>

<!-- Bug: Menu Items Not Labeled -->
<button>⚙️</button>
<ul>
  <li>Preferences</li>
  <li>Notifications</li>
  <li>Privacy</li>
</ul>

<!-- Missing structural landmarks -->
<!-- No <nav>, no <header> anywhere on page -->

Why This Matters

For a screen reader user, navigating a page without landmark regions means either reading through everything linearly or using heading navigation — neither of which reveals where the navigation menu lives. NVDA and JAWS both support landmark navigation via keyboard shortcuts (D for landmarks in NVDA, R in JAWS). Without a <nav> element, those shortcuts return nothing useful.

The missing aria-label on the hamburger button is a different failure. A button containing only ☰ — a Unicode character — may be announced as "trigram for heaven" by some screen readers, or simply as a symbol. Neither tells a user this opens a navigation menu. The button exists; its purpose does not.

The absent aria-expanded attribute is arguably the most disorienting failure of the three. When a sighted user clicks a hamburger menu, they see it open. When a screen reader user activates a button with no state management, the menu may appear in the DOM with no announcement. They've triggered something — but what? Is it open? Did anything happen? They must navigate away and back to discover the new content exists.

role="menu" and role="menuitem" aren't just semantic decoration. They activate specific keyboard interaction patterns that assistive technology users expect: arrow keys to navigate items, Escape to close, Home/End to jump to first/last item. A plain <ul> with <li> elements doesn't carry those interaction contracts.

Switch users and keyboard-only users face similar disorientation. Without proper ARIA states, the relationship between button and menu is invisible to the accessibility tree. The visual affordance — a button that opens a panel — has no programmatic equivalent.

Best Practices

The corrected pattern addresses both the structural landmarks and the ARIA interaction layer:

<header role="banner">
  <nav aria-label="Main navigation">
    <button
      aria-label="Menu"
      aria-expanded="false"
      aria-haspopup="menu"
      aria-controls="main-menu"
    >☰</button>

    <ul id="main-menu" role="menu" hidden>
      <li role="none">
        <a href="/" role="menuitem">Home</a>
      </li>
      <li role="none">
        <a href="/about" role="menuitem">About</a>
      </li>
      <li role="none">
        <a href="/contact" role="menuitem">Contact</a>
      </li>
    </ul>
  </nav>
</header>

The JavaScript managing this button must toggle aria-expanded between "true" and "false" on open/close, and remove the hidden attribute from the menu:

const menuButton = document.querySelector('[aria-haspopup="menu"]');
const menu = document.getElementById('main-menu');

menuButton.addEventListener('click', () => {
  const isExpanded = menuButton.getAttribute('aria-expanded') === 'true';
  menuButton.setAttribute('aria-expanded', String(!isExpanded));
  menu.hidden = isExpanded;
});

The WCAG Understanding document for 1.3.1 (opens in new window) and the ARIA Authoring Practices Guide on Disclosure Navigation (opens in new window) both provide authoritative reference for these patterns.

Applying This

Development teams can catch most of these issues before they ship:

Automated testing will flag missing landmarks and unlabeled buttons. Tools like axe-core, Lighthouse, and IBM Equal Access Checker all detect absent <nav> elements and buttons without accessible names. But as our research paper Beyond Detection documents, automated tools catch at most 37% of real accessibility barriers. The aria-expanded state failure — a button that has a label but no state management — may pass automated checks while still leaving screen reader users disoriented.

Code review should include a ARIA state checklist for any interactive component that shows/hides content: Does the trigger announce its current state? Does the container have the right role? Are keyboard interactions implemented per the APG pattern?

Design review should flag icon-only buttons before they reach development. If a button's purpose isn't legible without its icon, it needs a label — visible or via aria-label. This is faster to fix in Figma than in production.

For teams managing multiple compliance frameworks simultaneously, the Compliance Framework Paradox research is worth reviewing — WCAG 1.3.1 and 4.1.2 align directly with Section 508 requirements, so fixing these patterns satisfies multiple standards at once.

CORS Perspective

From a Risk/Legal Priority lens, icon button failures sit at an uncomfortable intersection: they're technically detectable by automated tools, which means they appear in litigation exhibits and DOJ technical findings, yet they're also among the most commonly deferred fixes because teams underestimate their user impact. Title II entities under the DOJ's 2024 final rule face specific scrutiny on interactive components — a hamburger menu that announces nothing to a screen reader user isn't a minor gap, it's a navigational barrier that may prevent access to the entire site structure. The strategic case for fixing these patterns is straightforward: the fix is small, the ARIA patterns are well-documented, and the legal exposure from leaving them broken is disproportionate to the effort required to resolve them.