Icon Menu Failures: The Community Has Been Saying This for Years

David's organizational diagnosis in his analysis of icon menu testing gaps is accurate as far as it goes. Workflow breakdowns, absent accountability structures, tooling that catches skeletons but not systemic rot — all of that is real. But after covering this beat for fifteen years, I keep returning to a question his framing sidesteps: who has been telling organizations about these failures, and what happened when they did?

The hamburger menu has been broken in the same ways for over a decade. That's not just a workflow problem. It's a feedback loop problem. The communities most affected by these failures have been reporting them through support channels, app store reviews, social media, and formal accessibility complaints — and that signal has been systematically underweighted in product cycles.

What Disabled Users Have Been Documenting

The WebAIM Million (opens in new window) data David cites is real and damning. But WebAIM's annual survey of screen reader users tells a parallel story that gets far less attention. The 2021 Screen Reader User Survey (opens in new window) found that 85.3% of respondents rated their screen reader experience as "somewhat" to "very" problematic. Navigation menus ranked among the most commonly cited pain points. These aren't abstract WCAG violations. They're reported experiences from people who encounter broken hamburger menus daily.

The gap between that survey data and organizational behavior isn't primarily a knowledge gap or even a workflow gap. It's a prioritization gap — and prioritization is driven by whose voice carries weight in product decisions.

This is where our approach to accessibility coverage differs from compliance-first framing. WCAG conformance is a floor, not a ceiling. The organizations that treat it as a ceiling are often the same ones with no structured mechanism for disabled users to report navigation failures and see those reports influence a sprint.

The Feedback Loops Organizations Are Missing

Consider what a genuine community feedback loop would look like for something as specific as icon button menu failures. A screen reader user encounters an unlabeled hamburger menu on a government site. They can't access the navigation. They have a few options: abandon the task, call a phone number if one exists, file a formal complaint with the Department of Justice (opens in new window), or post about it publicly.

The DOJ complaint route is slow — often measured in years, not sprints. The DOJ's 2024 final rule on web accessibility under Title II (opens in new window) adds legal weight, but enforcement timelines don't map to product cycles. Phone alternatives, where they exist, route around the digital failure rather than documenting it in a way that reaches engineering teams. Social media posts reach other disabled users, not product managers.

None of these pathways reliably closes the loop between a specific broken component and the team with authority to fix it. As explored previously in this analysis of testing gaps, the organizational problem is real — but organizations can't fix what they're not hearing about through channels they're monitoring.

The Section 508 program (opens in new window) requires federal agencies to report accessibility conformance, but those reports are primarily self-assessments. They don't aggregate user-reported failures in a way that surfaces specific component patterns like icon button menu breakdowns.

What Meaningful Community Input Actually Requires

The ARIA Authoring Practices Guide (opens in new window) exists. The guidance is clear. David is right that the violations persist despite the documentation. But the APG is written for developers, reviewed by developers, and tested primarily by developers using assistive technology — not by people who rely on that technology daily as their primary interface.

This distinction matters more than it sounds. Usability research on assistive technology consistently shows gaps between what developers expect AT users to do and what AT users actually do. The Great Lakes ADA Center (opens in new window) and peer regional ADA centers have documented repeatedly that accessibility training programs produce better outcomes when they include direct input from disabled people — not just technical standards review.

The W3C's own process for developing WCAG (opens in new window) includes public comment periods and working group participation open to disabled individuals. But working group participation requires time, technical literacy, and often employer support — resources unevenly distributed across the disability community. The people most affected by broken hamburger menus on mobile government sites are not, as a rule, the same people with capacity to participate in W3C working groups.

This is a structural gap that workflow improvements alone won't close. You can implement every recommendation David's organizational frame suggests — dedicated accessibility QA, pre-commit hooks, component library ownership — and still ship a hamburger menu that fails users in ways your testing didn't surface, because your testing didn't include the people who would have caught it.

The CORS Lens on Community Input

At this publication, our analytical framework treats community input not as a supplementary consideration but as a primary data source. When the same failures persist across a decade despite improved tooling and increased developer awareness, the missing variable is almost always feedback from affected communities that never reached decision-makers.

For icon button menu failures specifically, this means organizations need structured pathways for disabled users to report specific component failures — not general accessibility feedback forms, but mechanisms that capture enough technical context (browser, AT, task attempted) to be actionable. It means those reports need to reach engineering teams with authority to fix components, not just customer service teams authorized to apologize.

Several disability-led organizations have published guidance on building these pathways. Disability Rights Advocates (opens in new window) and similar legal advocacy organizations have documented in litigation what happens when these pathways are absent: years of reported failures, no organizational response, and eventual enforcement action that could have been avoided — not because litigation is the point, but because the absence of a feedback loop meant real people were denied access for years with no remedy.

What the Decade of Stagnation Is Actually Telling Us

Building on the organizational framework David establishes, the decade of stagnation in WebAIM Million data isn't just evidence that workflow accountability is missing. It's evidence that the feedback systems organizations rely on are structurally biased toward the voices of people who don't experience these failures.

Automated scanners report to developers. Compliance audits report to legal teams. User research, where it happens, often excludes disabled participants due to recruitment failures or testing environment limitations. The people who know exactly how broken these menus are — because they encounter them daily — are reporting through channels that don't connect to the teams with authority to fix them.

The practical implication is concrete: if your organization has an accessibility feedback form that routes to customer service, you have a listening gap. If your sprint retrospectives don't include a standing review of AT-user-reported failures, you have a listening gap. If your component library was last tested by a developer with a screen reader rather than a screen reader user, you have a listening gap. Closing it doesn't require a compliance program overhaul — it requires deciding that the people most affected by these failures are worth building a direct line to.

That's the gap nobody talks about. Not the testing gap. The listening gap.