Icon Button Failures Start in Design Systems, Not Code

Patricia's audit of icon button menus correctly identifies WCAG violations at the implementation layer. But the more consequential question is why these same failures reproduce across codebases at scale — and the answer points upstream, to design systems and component libraries that ship broken patterns as defaults.

In her analysis of icon button menu failures, Patricia documents a familiar constellation: missing <nav> landmarks, absent ARIA state announcements, no banner region. These are Level A violations — the floor of WCAG conformance, not the ceiling. The fact that they appear together, on a test page explicitly constructed to demonstrate the problem, reflects something the accessibility field has been slow to confront directly. We keep auditing the same failures because we keep shipping the same components.

Design Systems as the Root Cause

Most production websites don't have developers hand-coding hamburger menus from scratch. They're pulling from internal design systems, open-source component libraries, or UI frameworks. When those upstream components ship without proper landmark structure or ARIA state management, every implementation inherits the deficit.

The WebAIM Million report (opens in new window) has tracked WCAG failure rates on the top one million homepages annually since 2019. Navigation and landmark failures consistently appear among the most common issues — not because developers are unaware of WCAG, but because the components they use weren't built with these requirements in their acceptance criteria. A developer pulling a hamburger menu from a popular React component library may have no visibility into whether that component handles aria-expanded, aria-controls, or landmark structure correctly.

This is the gap that Patricia's audit surfaces but doesn't fully pursue. The automated testing methodology she references accurately describes what tools catch versus what they miss — but the more strategic question is where in the production pipeline those tools are applied.

Shifting the Intervention Point

The Section 508 ICT Testing Baseline (opens in new window) and WCAG 2.1 success criteria (opens in new window) are written as conformance requirements against finished products. That framing makes sense legally, but it creates a perverse incentive structure: organizations invest in auditing shipped products rather than in building accessible components that don't require remediation.

From a strategic alignment perspective — which I explore in more detail in my analytical approach — the highest-leverage intervention isn't the post-launch audit. It's the component library review. An accessible hamburger menu component, built once with proper landmark structure, correct ARIA roles, and state management, eliminates the failure class across every product that consumes it.

Deque Systems' research on shift-left accessibility (opens in new window) has quantified this: finding and fixing accessibility issues in design and development costs roughly three times less than fixing them after launch, and orders of magnitude less than addressing them through legal remediation. The math is straightforward. The organizational will to act on it is less so.

What ARIA Patterns Actually Require

The specific failures Patricia documents — missing aria-expanded state, absent role="menu" and role="menuitem" structure — aren't obscure edge cases. The ARIA Authoring Practices Guide (opens in new window) from the W3C has documented the menu button pattern with working examples for years. The pattern is known. The implementation gap persists because knowing the pattern and building it correctly into a reusable component are different organizational capabilities.

Building a compliant menu button requires understanding the full interaction model: keyboard navigation with arrow keys, focus management when the menu opens and closes, correct state announcement on toggle, and proper landmark containment. Automated tools catch some of this — the missing landmark, the absent state attribute — but as Patricia's analysis makes clear, they don't catch the interactive failures that only surface under actual assistive technology testing.

This creates a two-layer problem for design systems teams. Structural violations are detectable at build time with tools like axe-core (opens in new window) integrated into CI/CD pipelines. Interactive failures require manual testing with screen readers — NVDA, JAWS, VoiceOver — across browser combinations. Both testing layers need to be part of the component acceptance criteria before anything ships.

The Organizational Accountability Gap

The DOJ's web accessibility guidance (opens in new window) issued in 2022 clarified that web accessibility is a Title II and Title III ADA requirement, reinforcing what courts had been finding for years. But legal exposure tends to concentrate at the product level — the website that fails, the app that excludes users. The design system that introduced the broken component three years earlier rarely appears in the remediation conversation.

This is a structural accountability failure. Organizations that treat accessibility as a compliance checkbox applied to finished products will keep cycling through the same audit-remediate-regress pattern. The people bearing the cost of that cycle are screen reader users who encounter the same broken navigation across every product built from the same broken library — not once, but everywhere that library was adopted.

Organizations that embed accessibility requirements into their design system governance — with component-level acceptance criteria, automated checks in the development pipeline, and periodic manual testing of interaction patterns — break that cycle structurally. The Great Lakes ADA Center (opens in new window) and other regional ADA centers have published resources on organizational accessibility planning that speak to this systems-level thinking. The conversation has to move from "did this page pass" to "does our component library produce pages that pass."

Patricia's audit is doing the right work at the right level of technical detail. The counterpoint isn't that the violations she found don't matter — they clearly do, and they affect real users navigating with screen readers right now. The counterpoint is that auditing broken implementations is necessary but not sufficient. The field needs to push harder on the upstream systems that generate those implementations, because that's where the pattern breaks — and where it can be fixed at scale.

The practical implication is concrete: if your organization runs annual accessibility audits but has no component-level acceptance criteria for ARIA patterns, you are funding the discovery of failures your own design system is scheduled to reproduce next quarter. The audit-first model doesn't fix that. Governance of the component library does.

You can review my full analytical framework for how I evaluate accessibility failures across the production lifecycle, and explore related coverage from our contributors on design system governance and component-level testing strategies.