Split Buttons Expose a Deeper Problem: We're Testing the Wrong Things

Patricia's analysis of split button dropdown failures is technically precise and practically useful. The bugs she documents — unlabeled arrow buttons, unannounced state changes, ambiguous primary actions — are real and consequential. But the split button case exposes something the accessibility field keeps circling without directly confronting: we have built our entire evaluation infrastructure around what automated tools can detect, and we've quietly allowed that constraint to define what we consider an "accessibility audit."

This isn't a criticism of automated testing. It's a structural observation about incentive systems.

The 37% Figure Is a Methodology Problem, Not a Benchmark

The research cited in the original piece — that automated tools catch at most 37% of real barriers — has become a frequently quoted figure in accessibility circles. But that statistic tends to generate a predictable response: practitioners nod, acknowledge the gap, and then continue using automated tools as the primary audit mechanism because they're fast, repeatable, and produce defensible documentation.

The problem isn't that organizations use automated tools. The problem is that the 37% figure has become a ceiling we've learned to live with rather than a floor we're trying to raise. According to WebAIM's annual accessibility analysis of the top one million websites (opens in new window), the most common WCAG failures detected automatically — missing alt text, low contrast, empty form labels — have shown marginal improvement over five years of consistent reporting. We keep measuring the same detectable errors. The undetectable ones, like the split button state management Patricia describes, remain largely invisible to organizational compliance programs.

Section 508 guidance from GSA (opens in new window) acknowledges this explicitly, distinguishing between automated, manual, and hybrid testing approaches. Yet procurement requirements and internal audit programs routinely specify automated scanning coverage percentages without equivalent requirements for manual testing depth.

What Split Buttons Actually Represent

The split button is an instructive case precisely because it's a composite widget — a primary action button joined to a disclosure trigger that controls a menu. The ARIA Authoring Practices Guide (opens in new window) documents the expected keyboard interaction model and semantic structure for menu buttons. The pattern is well-specified. The implementation failures Patricia documents aren't failures of specification — they're failures of translation between specification and production code.

This distinction matters for how we think about solutions. If the problem were specification gaps, the answer would be better documentation. But the ARIA specification for this pattern is thorough. The problem is that developers building split button components in React, Vue, or Angular are often working from design system components that were never audited for assistive technology compatibility. Those components get composed into products that pass automated scans because the scanner checks for the presence of button elements, not whether those button elements have meaningful names in context.

Deque's research on component-level accessibility (opens in new window) has consistently found that reusable component libraries carry accessibility debt forward at scale — one flawed component pattern can propagate across hundreds of product surfaces simultaneously.

The Stakeholder We're Not Centering

As explored in the original analysis, the scanner caught landmark violations while missing the semantic failures that make the widget genuinely unusable. That framing centers the tool. The more important stakeholder is the screen reader user who encounters this widget in a real task flow.

For a user navigating with JAWS or NVDA, encountering a button announced simply as "button" adjacent to a "Download" button creates a genuine decision point. Is this a duplicate? A secondary action? A settings trigger? The cognitive overhead of resolving that ambiguity — or abandoning the task — is the actual accessibility impact. That impact doesn't appear in any automated report.

The Pacific ADA Center (opens in new window) and similar regional technical assistance centers have long emphasized that accessibility is fundamentally about functional equivalence — whether disabled users can accomplish the same tasks with comparable effort. A split button that passes six automated checks while requiring screen reader users to guess at functionality is not functionally equivalent, regardless of its scan score.

This connects to what we describe in our analytical approach at Accessibility Observer: compliance documentation and actual usability are related but distinct outcomes. Organizations that conflate them tend to accumulate scan scores while accumulating barriers.

The Implementation Reality

Development teams building split buttons face a specific challenge that audit reports rarely surface: the accessible name for the arrow trigger requires a deliberate design decision about what that name should actually communicate. aria-label="More options" is generic. aria-label="More download options" is specific but verbose. aria-label="Download options menu" provides action context. Each choice carries different implications for screen reader announcement patterns and user mental models.

This is a design problem, not just a coding problem. Design problems require design review processes that include accessibility expertise — not post-hoc scanning. The DOJ's guidance on web accessibility (opens in new window) under Title II and Title III consistently frames accessibility as a design and development practice, not a remediation activity. Most organizational accessibility programs are structured around remediation.

Building on the framework Patricia establishes around specific WCAG criteria violations, the more durable intervention isn't fixing individual split button implementations — it's establishing component acceptance criteria that require assistive technology testing before any reusable component enters a design system. That shifts the economics: one thorough review prevents propagation rather than requiring repeated remediation across every surface where the component appears.

The split button is small. The gap it exposes is not. Until accessibility programs are structured around what users experience rather than what scanners detect, that gap will keep producing the same findings, the same reports, and the same unlabeled arrow buttons announcing themselves as "button" to users who deserve better.