Split Button Dropdown Arrows: A Small Widget, A Big Gap

The automated analysis of this split button test page (opens in new window) passes six button checks and fails two landmark checks. That scorecard looks reassuring — until you read what the page itself documents as the actual bugs: dropdown arrows without accessible names, menus that don't announce their open/closed state, and main button actions that are unclear to assistive technology. The static scanner caught the landmark gaps. It missed the semantic problems that make this widget genuinely unusable.

That gap between what automated tools detect and what actually blocks users is the central tension in modern accessibility auditing. Our research paper Beyond Detection: Why Context Separates Automated Testing from Manual Audits documents that automated tools catch at most 37% of real barriers. This split button page is a clean illustration of why.

The Finding

The test page (opens in new window) documents three distinct failure patterns across three split button examples — Download, Save, and Share. The automated scan identified two structural violations: missing <nav> and <header> landmarks. Those matter, but they're not the accessibility story here.

The documented bugs are:

Bug 1 — Arrow button has no accessible name. The dropdown trigger (▼ or ▾ or ⋮) is a button containing only a visual symbol. Without an aria-label, screen readers announce it as "button" with no indication of what it does or which primary action it extends.

Violates WCAG 4.1.2 Name, Role, Value (opens in new window) and WCAG 1.1.1 Non-text Content (opens in new window).

<!-- Bug: Arrow button with no accessible name -->
<div class="split-button">
  <button>Download</button>
  <button>▼</button>  <!-- screen reader: "button" -->
</div>

Bug 2 — Dropdown state not announced. When the menu opens, nothing communicates that change to assistive technology. Missing aria-expanded means a screen reader user has no way to know whether their keypress opened a menu or did nothing.

Violates WCAG 4.1.2 Name, Role, Value (opens in new window).

<!-- Bug: No state communication -->
<button>▾</button>  <!-- no aria-expanded, no aria-haspopup -->

Bug 3 — Main button action is ambiguous. When the primary button and the dropdown arrow are not programmatically linked, the relationship between them is invisible to assistive technology. The user hears two separate buttons with no structural connection.

Violates WCAG 4.1.2 Name, Role, Value (opens in new window).

Why This Matters

Split buttons appear constantly in productivity interfaces — document editors, email clients, form builders, content management systems. The pattern is almost always the same: a primary action button paired with a small dropdown trigger for secondary options.

For a sighted mouse user, the visual grouping is obvious. For a screen reader user navigating by Tab, the experience without proper ARIA is this: "Download button. Button." Two buttons. No relationship. No indication that the second button opens a menu, no indication of what that menu contains, and no feedback when it opens or closes.

For a keyboard-only user, the broken aria-expanded state creates a different problem: they can't tell if their keypress worked. Did the menu open? Did it close? Is focus inside the menu or still on the button? Without state announcements, navigation becomes guesswork.

Switch users and voice control users face compounding issues. A voice control user trying to activate "Download options" by speaking the label will fail if that label doesn't exist in the DOM — the visual arrow is not a label.

Best Practices

The corrected pattern requires three things: an accessible name on the dropdown trigger, aria-expanded to communicate state, and aria-haspopup to signal that a menu will appear.

<!-- Fixed: Complete split button pattern -->
<div class="split-button" role="group" aria-label="Download options">
  <button type="button">Download</button>
  <button
    type="button"
    aria-label="Download options"
    aria-expanded="false"
    aria-haspopup="menu"
  >▼</button>
</div>

<!-- Fixed: Menu with proper role and labeling -->
<ul role="menu" aria-label="Download options" hidden>
  <li role="menuitem">Download as PDF</li>
  <li role="menuitem">Download as CSV</li>
  <li role="menuitem">Download as ZIP</li>
</ul>

When the menu opens, JavaScript must toggle aria-expanded="true" on the trigger button and remove the hidden attribute from the menu. When it closes, reverse both. Focus management also matters: opening the menu should move focus to the first menu item; pressing Escape should close the menu and return focus to the trigger.

The ARIA Authoring Practices Guide for Menu Button (opens in new window) provides the full keyboard interaction model, including arrow key navigation within the menu.

For the landmark violations the scanner did catch: add a <header> element wrapping the page banner content and a <nav> element if the page contains navigation links. These are WCAG 1.3.6 Identify Purpose (opens in new window) and WCAG 2.4.1 Bypass Blocks (opens in new window) concerns that affect how efficiently screen reader users can orient themselves on a page.

Applying This

Development teams can catch the accessible name violation with automated tools — axe-core and Lighthouse will flag a button with no text content and no aria-label. But aria-expanded state management is behavioral: it requires JavaScript to toggle correctly, and most static scanners won't catch a missing toggle that only fails at runtime.

Code review checklist additions that would catch these patterns:

• Any button containing only a symbol (▼ ▾ ⋮ × +) must have an explicit aria-label
• Any button that opens a menu must have aria-haspopup and aria-expanded
• Any aria-expanded attribute must have corresponding JavaScript that toggles it
• Split button groups should use role="group" with a descriptive aria-label

This is also a design system problem. If the split button component is built correctly once — with all ARIA attributes wired to state — every instance inherits the fix. If it's built incorrectly once, every instance inherits the bug. The Compliance Framework Paradox research examines how component-level decisions like this propagate across entire products, often invisibly.

One more dimension worth naming: accessible names on interactive controls must also work in translation. A screen reader user who navigates in Spanish or Vietnamese needs "Opciones de descarga" or "Tùy chọn tải xuống" — not the English string. idioma.chat (opens in new window) addresses this directly: it translates not just visible page text but the full accessibility layer, including aria-label attributes, aria-describedby content, and dynamically toggled state strings. A split button with a correctly labeled dropdown trigger is still a barrier if the label only exists in one language. Language access and disability access are the same access problem, addressed in different silos.

CORS Perspective

From a Risk/Legal Priority lens, split button violations sit in a specific danger zone: they're invisible to casual review, they're embedded in reusable components, and they scale. A single inaccessible split button component deployed across a government portal or enterprise SaaS product creates thousands of individual WCAG 4.1.2 failures — each one a potential litigation data point. The Settlement Trap research documents how exactly this kind of systemic, component-level failure survives post-settlement remediation because organizations fix individual pages rather than fixing the component. The strategic fix here isn't patching three buttons. It's auditing every interactive component in the design system for missing ARIA state management — then building the correct pattern once.