Icon Menus: The Testing Gap Nobody Talks About

Patricia's analysis of icon button menu failures lands on something real: the gap between what automated tools detect and what actually breaks for users. Two WCAG 1.3.1 violations, missing landmarks, absent state announcements — the skeleton of a problem, as she puts it. After fifteen years covering accessibility failures across healthcare, government, and e-commerce, I'd push the frame further. The skeleton isn't the gap. The gap is organizational.

The hamburger menu has been broken in the same ways, on the same types of sites, for over a decade. That's not a tooling problem. That's a workflow problem.

What the WebAIM Million Data Actually Shows

The WebAIM Million (opens in new window) report, which analyzes the top one million home pages annually, has tracked navigation-related failures since 2019. Missing ARIA labels on interactive controls consistently rank among the top five error categories — year after year. The 2024 report found that 96.3% of home pages had detectable WCAG failures, with a mean of 56.8 distinct errors per page.

Those numbers haven't improved meaningfully in five years. Automated tools have gotten better. Awareness has increased. The DOJ's final rule on web accessibility (opens in new window) under Title II of the ADA, published in 2024, has added legal pressure that didn't exist before. And still: 96.3%.

The problem Patricia documents — unlabeled hamburger menus, missing state announcements, absent role structure — isn't a knowledge gap at the developer level. Most developers working on production codebases in 2024 have encountered ARIA documentation. The ARIA Authoring Practices Guide (opens in new window) from the W3C explicitly covers disclosure navigation patterns, including the exact menu-button pattern at issue. The guidance exists. The violations persist.

The Organizational Reality Behind Persistent ARIA Failures

Here's the counterpoint I want to make: automated audits are necessary but insufficient not because of what they miss technically, but because of where they sit organizationally.

When a scanner flags missing <nav> landmarks or absent aria-expanded states, that finding enters a ticket queue. In most organizations I've reported on, that queue is triaged by product managers working against roadmaps that weren't built with accessibility remediation in mind. A Level A violation competes with feature requests, performance work, and design debt. Without organizational structures that treat accessibility findings as blocking issues, automated audits become documentation of known problems rather than catalysts for change.

The Section508.gov guidance on accessibility testing (opens in new window) makes this explicit for federal agencies: testing is one phase of a broader process that includes remediation planning, tracking, and verification. The testing phase is not the end state. For many private-sector organizations, it functions as exactly that.

This is the implementation reality that Patricia's technical analysis necessarily brackets. A compliance audit documents what's broken. It doesn't tell you why the same patterns keep breaking across different codebases, different teams, different years.

The Component Library Problem

One underexamined factor: the proliferation of third-party component libraries that ship inaccessible patterns by default.

When a development team reaches for a pre-built hamburger menu component — from a UI kit, a design system, or an npm package — they often inherit whatever accessibility decisions the original author made. If that component lacks aria-expanded state management or ships without landmark context, every implementation inherits those failures. The team may never write a single line of the broken code.

The ARIA Authoring Practices Guide (opens in new window) addresses this at the pattern level, but component library maintainers operate under their own pressures. Accessibility fixes require testing with actual assistive technologies, which requires time and expertise that many open-source maintainers don't have. The result is a supply chain of accessible-looking but technically broken UI components that get deployed at scale.

This is a different problem than developer ignorance, and it requires different solutions. Procurement policies, vendor assessments, and design system governance matter here more than individual developer training.

What Balanced Analysis Requires

At this publication, we try to hold technical findings and organizational context together rather than treating them as separate conversations. The technical violations Patricia documents are real and consequential. Screen reader users navigating a page without landmark structure face genuine barriers — they lose the ability to skip to main content, to orient themselves within the page, to understand the relationship between the header and the navigation it contains. That's not a compliance abstraction. It's a person unable to use a site.

But the analytical frame that stops at "here's what's broken and here's the WCAG criterion" leaves practitioners without a map for why the same things keep breaking. The Great Lakes ADA Center (opens in new window) and other regional ADA Centers have documented this in their technical assistance work: organizations often know their digital properties have accessibility problems. The barrier isn't awareness. It's prioritization, resourcing, and accountability structures.

The DOJ's 2024 Title II rule creates new legal pressure that may shift those structures for state and local government entities. For private-sector organizations, the picture is more uneven. Litigation risk varies by sector and organization size. Voluntary remediation without external pressure remains inconsistent — which means the people bearing the cost of inaction are screen reader users, not the organizations responsible for the broken code.

Screen Reader Testing Catches What Scanners Miss — But That's Not the Bottleneck

One place I'd push back gently on the framing in the original analysis: the gap between automated and manual testing is real, but it's not the primary variable in whether icon button menus get fixed.

Manual testing with screen readers — NVDA, JAWS, VoiceOver — will surface the interactive failures that automated tools miss. The experience of tabbing to an unlabeled button, hearing nothing descriptive announced, activating it and receiving no state feedback: that's the failure that matters to users. Automated tools catch the structural preconditions. Manual testing catches the lived experience.

But organizations that don't act on automated findings are unlikely to act on manual testing findings either. The bottleneck isn't detection methodology. It's what happens after detection.

Building on the framework established in Patricia's analysis, the productive next question isn't only "what do automated tools miss?" It's "what organizational conditions make remediation likely once findings exist?" That's a harder question. It's also the one that determines whether any of this testing work translates into better experiences for the screen reader users navigating broken hamburger menus right now.

For practitioners, that question has a concrete starting point: find out where accessibility findings go after they're filed. If the answer is a backlog with no blocking criteria and no remediation owner, the testing methodology is the least of the problem.