Split Buttons Aren't the Problem. Component Libraries Are.

The ARIA fix for split button menus is well-documented. So why do the same failures appear across enterprise dashboards year after year? The answer isn't developer ignorance — it's a systemic failure baked into how component libraries get built, distributed, and trusted.

Jamie's recent analysis of split button popup menu failures correctly identifies the technical gap: unlabeled trigger buttons, missing aria-expanded, absent role="menu" structure. The WCAG 1.3.1 and 4.1.2 failures are real and consequential. But diagnosing the pattern at the component level, while accurate, stops short of the more uncomfortable question: who put that broken component in the library that thousands of developers are pulling from npm right now?

The Library Trust Problem

Enterprise development teams don't build split buttons from scratch. They reach for Material UI (opens in new window), Ant Design (opens in new window), Radix UI (opens in new window), or their organization's internal design system. When those components ship with ARIA gaps, every downstream implementation inherits the failure — regardless of how accessibility-aware the consuming developer might be.

This isn't a hypothetical. The WebAIM Million report (opens in new window) has documented for years that the most common WCAG failures cluster around interactive controls — buttons, form inputs, links — precisely the elements that component libraries are supposed to abstract away. In the 2024 report, 95.9% of home pages had detectable WCAG failures. That number doesn't move because individual developers are careless. It doesn't move because the infrastructure they build on hasn't moved.

The Deque Systems accessibility research (opens in new window) consistently shows that automated testing catches roughly 30–40% of accessibility issues. Jamie's analysis demonstrates this directly — the split button passes automated checks while failing screen reader users completely. But the deeper implication is that component library maintainers often rely on the same automated tooling to validate their components before release. A library can ship, pass CI/CD accessibility gates, and still deliver a nameless button in a void to JAWS users.

What Balanced Analysis Requires Here

The approach we take at this publication is to examine accessibility failures across four dimensions: community impact, operational reality, risk distribution, and strategic implications. Applying that lens to split button failures reveals something the technical fix alone doesn't address.

The community impact is clear and Jamie documents it well — screen reader users navigating enterprise tools encounter interaction dead zones that sighted users never see. These aren't edge cases or minor friction points; they are complete barriers to task completion for people who depend on assistive technology. But the operational reality is more complex. A mid-size development team consuming a third-party component library has limited leverage over that library's accessibility roadmap. Filing a GitHub issue is not the same as shipping a fix. And forking a library to patch ARIA attributes creates a maintenance burden that compounds over time.

The risk distribution here is also asymmetric in ways worth examining. When a split button ships without aria-haspopup and aria-expanded, the legal and reputational risk lands on the organization deploying the interface — not on the library that provided the broken component. The Department of Justice's 2024 final rule (opens in new window) on web accessibility under Title II of the ADA makes clear that public entities are responsible for the accessibility of their digital services, full stop. The provenance of a component is not a defense.

This creates a perverse incentive structure. Library maintainers face limited direct accountability for ARIA failures. Consuming organizations face full accountability. Yet consuming organizations often lack the expertise or access to audit and remediate what they're importing.

The Design System Accountability Gap

Section 508 of the Rehabilitation Act, administered through the U.S. Access Board (opens in new window) and Section508.gov (opens in new window), applies directly to federal agencies and their contractors. Federal procurement increasingly requires vendors to provide Accessibility Conformance Reports (opens in new window) based on the VPAT framework. This is meaningful pressure — but it applies to a narrow slice of the software ecosystem.

For the broader commercial market, there's no equivalent accountability mechanism for component library publishers. A library can advertise "accessibility support" in its documentation while shipping the exact pattern Jamie's analysis flags: a trigger button with no name, no state, no role. The advertising is not regulated. The claim is not audited.

The Pacific ADA Center (opens in new window) and other regional ADA centers have published technical assistance materials on digital accessibility, but these resources are primarily oriented toward organizations building and deploying interfaces — not toward the upstream infrastructure those organizations depend on.

What This Means for Practitioners

As explored in the original analysis, the correct ARIA pattern for split buttons is specific and implementable: aria-label on the trigger, aria-expanded toggling on interaction, aria-haspopup="menu" declaring intent, role="menu" and role="menuitem" providing structure. The ARIA Authoring Practices Guide (opens in new window) from the W3C documents this pattern in detail.

But practitioners operating within component library constraints need a parallel strategy. Before adopting any component library for an enterprise application, run the library's interactive components — especially split buttons, dropdowns, and comboboxes — through manual screen reader testing with NVDA and JAWS, not just automated tooling. Check the library's issue tracker for open accessibility bugs. Review whether the library publishes an accessibility conformance statement. These steps won't fix a broken library, but they surface risk before it becomes your organization's legal exposure — and before disabled users encounter the barrier in production.

For teams with the capacity to contribute upstream, filing detailed ARIA bug reports with reproduction cases is more effective than workarounds. Libraries like Radix UI have demonstrated that accessibility-first component design is achievable — their primitives are built around accessible patterns from the ground up. That model exists. The question is whether the broader ecosystem adopts it or continues shipping triangles that mean nothing to a screen reader.

The Systemic Fix

Building on the technical framework Jamie establishes, the path forward requires action at two levels simultaneously. At the component level: implement the correct ARIA pattern, test with real assistive technology, and treat screen reader behavior as a first-class acceptance criterion. At the ecosystem level: organizations need to audit their component dependencies, procurement processes need to include accessibility conformance requirements, and the industry needs to stop treating "automated testing passes" as a proxy for "accessible."

The Great Lakes ADA Center (opens in new window) frames digital accessibility as an ongoing process rather than a one-time audit — a framing that applies equally to component library maintenance. Accessibility conformance isn't a checkbox that a library ticks at version 1.0 and carries forward. It requires active maintenance, user testing with disabled people, and accountability structures that currently don't exist for most of the open-source component ecosystem.

The split button ARIA gap is fixable in an afternoon. The conditions that keep shipping it across thousands of applications are not. The concrete next step for any team evaluating a component library today: open the library's demo environment, launch NVDA or JAWS, and navigate to a split button. What you hear — or don't hear — tells you more than any documentation claim about accessibility support.