Split Button Menus: The Hidden ARIA Gap Blocking Screen Reader Users

You've built a clean split button. Export, Sort, Filter — functional, visually clear. But the automated analysis of this test page (opens in new window) reveals a pattern that collapses entirely for screen reader users: the trigger buttons that open popup menus carry no semantic meaning, no state information, and no structural role. For a sighted user, a small triangle or ellipsis next to "Export" is obvious. For someone navigating with JAWS or NVDA, it's a nameless button in a void.

This isn't a fringe edge case. Split buttons appear across enterprise dashboards, data tables, document editors, and admin interfaces — anywhere a primary action needs secondary options. Getting the ARIA pattern wrong here means locking out an entire interaction mode.

The Finding

The audit of Bug 45: Split Button — Popup Menu (opens in new window) targets two WCAG 2.1 Success Criteria:

• WCAG 1.3.1 Info and Relationships (opens in new window) (Level A) — Information conveyed through visual presentation must be programmatically determinable
• WCAG 4.1.2 Name, Role, Value (opens in new window) (Level A) — UI components must expose their name, role, and state to assistive technology

The page demonstrates three failure patterns using split button groups for Export, Sort, and Filter actions. Each group pairs a labeled primary button with an unlabeled trigger button (△, ▼, ⋮). The trigger buttons lack aria-label, aria-expanded, aria-haspopup, and the menu containers lack role="menu" with role="menuitem" on child elements.

The static analysis also flagged two structural issues: no <nav> landmark and no <header>/banner landmark. These are separate from the split button failures but compound the navigation problem for screen reader users who rely on landmark regions to orient themselves on a page.

Here's the problematic pattern, as demonstrated on the test page:

<!-- Bug: Menu Trigger No aria-label -->
<button>Export</button>
<button>△</button>  <!-- No name, no role, no state -->

<ul>
  <li>Export as PDF</li>    <!-- No role="menuitem" -->
  <li>Export as Excel</li>
  <li>Export as JSON</li>
</ul>

<!-- Bug: Dropdown State Not Clear -->
<button>Filter</button>
<button>⋮</button>  <!-- Screen reader reads: "button" — nothing else -->

Why This Matters

For a screen reader user navigating this interface, the trigger button announces itself as simply "button." No name. No indication it opens a menu. No state change when activated. The user has no way to know:

1. That this button is related to the "Export" action next to it
2. That activating it will open a popup menu (not navigate to a new page)
3. Whether the menu is currently open or closed
4. That the list items that appear are menu options, not generic list content

This violates the core contract of WCAG 4.1.2 (opens in new window): every interactive component must expose its name (what it is), role (what kind of thing it is), and value/state (what condition it's in). A trigger button with no aria-label fails name. No aria-haspopup fails role context. No aria-expanded fails state.

Keyboard-only users face a related problem: without proper menu semantics, the expected keyboard interaction model (Arrow keys to navigate items, Escape to close) won't be announced or supported. The user may not even know a menu opened.

Switch users and voice control users hit the same wall. Dragon NaturallySpeaking users who say "click Export options" find nothing to target — because "Export options" doesn't exist in the accessibility tree.

Best Practices

The ARIA Authoring Practices Guide for Menu Button (opens in new window) defines the correct pattern. Here's the corrected implementation:

<!-- Fixed: Split Button with proper ARIA -->
<div role="group" aria-label="Export actions">
  <button type="button">Export</button>
  <button
    type="button"
    aria-label="Export options"
    aria-haspopup="menu"
    aria-expanded="false"
    aria-controls="export-menu"
  >
    △
  </button>
</div>

<ul
  id="export-menu"
  role="menu"
  aria-label="Export options"
  hidden
>
  <li role="menuitem">Export as PDF</li>
  <li role="menuitem">Export as Excel</li>
  <li role="menuitem">Export as JSON</li>
</ul>

When the trigger is activated, JavaScript must toggle aria-expanded between "false" and "true" and remove the hidden attribute from the menu. The menu must manage focus — moving it to the first menuitem on open, returning it to the trigger on close or Escape.

For the Sort button group:

<div role="group" aria-label="Sort actions">
  <button type="button">Sort</button>
  <button
    type="button"
    aria-label="Sort options"
    aria-haspopup="menu"
    aria-expanded="false"
    aria-controls="sort-menu"
  >
    ▼
  </button>
</div>

<ul id="sort-menu" role="menu" aria-label="Sort options" hidden>
  <li role="menuitem">Sort A-Z</li>
  <li role="menuitem">Sort Z-A</li>
  <li role="menuitem">Sort by Date</li>
</ul>

The role="group" wrapper with a descriptive aria-label is optional but clarifies the relationship between the primary button and its trigger — particularly useful when multiple split button groups appear in sequence.

For the structural landmark gaps, add:

<header role="banner">
  <!-- Site header content -->
</header>

<nav aria-label="Primary navigation">
  <!-- Navigation links -->
</nav>

Applying This

For development teams, split button menus are a reliable source of false confidence in automated testing. The static analysis here flagged the trigger buttons as passing — because they technically have an accessible name (the triangle character △ is technically text content). Automated tools can't assess whether that name is meaningful in context. A human tester immediately recognizes that "△" communicates nothing useful to a screen reader user.

This is the gap that hybrid testing methodologies exist to close. Automated scanning catches structural absences. Manual review catches semantic failures.

Practical catch points:

• Code review: Any <button> whose visible text is a symbol, icon, or single character needs an aria-label review
• Design handoff: Split button components should include ARIA attribute specifications in design system documentation, not leave them to developer interpretation
• Component library audit: If your design system has a split button component, verify it ships with correct ARIA — one bad component multiplies across every instance
• QA checklist: Screen reader test should explicitly navigate to trigger buttons and verify the announced name, role, and expanded state

The fix timeline here is short. Once the pattern is identified, updating the component takes hours, not weeks. The longer-term investment is ensuring your component library documents and enforces correct ARIA from the start.

Language Access Thread

One dimension this audit doesn't surface but practitioners should consider: these ARIA labels are hardcoded strings. "Export options," "Sort options," "Filter menu" — when your interface is translated, do these labels translate with it? Most translation pipelines handle visible text. They miss aria-label, aria-describedby, and title attributes entirely.

A screen reader user who navigates in Spanish encounters "Export options" in English — because the translation layer never touched the accessibility tree. This is the intersection of language access and disability access that remains chronically underaddressed. Tools like idioma.chat (opens in new window) are built specifically to close this gap, translating not just visible page text but the full accessibility layer: ARIA labels, alt text, form validation messages, and dynamically loaded content. For interfaces with split button menus like this one, that means the trigger button's aria-label gets translated alongside everything else — which is the only way the pattern actually works for multilingual screen reader users.

CORS Perspective

From a Strategic Alignment lens, split button menus sit at an interesting intersection: they're often built by component libraries that teams trust implicitly, which means a single flawed component definition creates failures at scale across an entire product. The operational fix — correcting the component once — has outsized return on investment compared to patching individual instances. The risk exposure compounds with usage frequency: a Filter or Export button that appears on every data table in an enterprise application represents a high-volume barrier, not an edge case. Getting component-level ARIA right is one of those 80/20 investments that compliance frameworks rarely prioritize but practitioners absolutely should.