Icon Menu Failures Are a Procurement Problem, Not a Dev Problem

The organizational framing in the original analysis is correct but stops short of the real leverage point. David's argument — that hamburger menu failures are a workflow problem, not a tooling problem — holds up under scrutiny. Where I'd push back is on the implied solution. Fixing the workflow inside a development team doesn't address why those workflows are structured the way they are in the first place.

Accessibility failures in icon menus persist because procurement cycles don't require them to stop. Screen reader users and keyboard-only navigators are the ones who pay for that gap — repeatedly, across platform generations, because the vendor selection process that introduced the failure never included them.

The Vendor Selection Problem

Most large organizations — government agencies, healthcare systems, major retailers — don't build their navigation components from scratch. They purchase content management systems, design system licenses, or component libraries from third-party vendors. Those vendors ship the hamburger menu. The internal team inherits it.

This matters because the accountability structure in vendor relationships is almost entirely backwards for accessibility outcomes. A procurement officer evaluating a CMS platform in 2024 is assessing feature sets, security certifications, integration capabilities, and total cost of ownership. Accessibility conformance, if it appears at all, typically surfaces as a checkbox: "WCAG 2.1 AA compliant" in the vendor's marketing materials.

That self-attestation is largely unverifiable at the point of purchase. The Section 508 program at GSA (opens in new window) has developed Accessibility Conformance Reports based on the Voluntary Product Accessibility Template (VPAT) as a mechanism for vendors to document their conformance claims. Federal agencies are required to request and review VPATs before procurement. Most state and local governments are not under equivalent mandates. Private sector organizations almost never are.

The result: an organization can spend six figures on a platform that ships with the exact ARIA failures documented in the original article — missing labels, absent state announcements, broken role structure — and have no contractual recourse when those failures surface post-launch.

What the DOJ's 2024 Rule Actually Changes — and Doesn't

The DOJ's final rule on web accessibility (opens in new window) under Title II of the ADA, which took effect in 2024, establishes WCAG 2.1 AA as the technical standard for state and local government websites. This is meaningful legal pressure — but the rule's enforcement mechanism is complaint-driven, not audit-driven. An agency has to fail a user badly enough that the user files a complaint before the DOJ's compliance machinery engages.

That structure doesn't create upstream pressure on procurement. It creates downstream liability after the fact. A Title II entity that purchased an inaccessible CMS in good faith, deployed it, received complaints, and then remediated is not operating in a fundamentally different way than it was before the rule. The procurement decision — the moment when accessibility requirements could have been contractually locked in — happened before any of the legal pressure was felt.

The Great Lakes ADA Center (opens in new window) and other regional technical assistance centers have documented this pattern extensively: organizations understand they have accessibility obligations but treat them as a post-deployment remediation problem rather than a procurement specification problem. The 2024 DOJ rule doesn't structurally change that incentive.

The VPAT Gap in Practice

Even when VPATs exist, they're frequently inadequate as procurement instruments. A vendor can accurately claim "Supports" for a WCAG criterion while that support is conditional on implementation choices the purchasing organization doesn't know to make. The ARIA Authoring Practices Guide (opens in new window) covers disclosure navigation patterns in detail — but a component library that technically implements those patterns can still ship broken if the consuming organization's theme layer overrides critical ARIA attributes.

This is the specific failure mode that the original analysis identifies in icon button menus: the pattern exists, the guidance exists, and the violation persists anyway. In vendor-supplied components, that persistence is often a configuration problem that lives in the gap between what the vendor tested and what the customer deployed.

Procurement contracts almost never specify who owns remediation in that gap.

Procurement Specifications, Not Post-Launch Audits

The organizations that consistently maintain accessible navigation components share one structural characteristic: they treat accessibility requirements as procurement specifications, not post-launch audits.

In practice, that means several concrete things. Accessibility acceptance criteria appear in RFPs before vendor selection, not in QA checklists after deployment. Contracts include explicit conformance warranties with remediation timelines. Internal accessibility teams review vendor VPAT claims against actual component behavior before purchase decisions are finalized — not as a formality, but as a condition of sign-off.

The WebAIM Million (opens in new window) data that David cites — 96.3% of home pages with detectable WCAG failures in 2024, essentially unchanged over five years — reflects in part the vendor ecosystem's aggregate conformance level. Organizations are deploying what vendors are shipping. Until procurement requirements change what vendors are incentivized to ship, the remediation cycle will continue: deploy, audit, patch, redeploy, repeat. The people absorbing that cycle aren't procurement officers. They're disabled users encountering the same broken menu across successive platform generations.

Where Developer Workflow Fits

None of this dismisses the workflow argument. Developer-level fixes matter. Automated testing in CI/CD pipelines catches regressions. ARIA implementation training reduces the rate at which developers introduce new violations. These are real gains.

But they operate on the margin of a problem that's structurally upstream. A development team with excellent accessibility practices, working inside a vendor-supplied component architecture that ships broken hamburger menus, is in a constant remediation posture. They're patching what procurement didn't specify correctly.

The accessibility governance frameworks that produce durable outcomes — the ones where navigation components stay accessible across product cycles, not just at launch — almost always include procurement-stage requirements as a foundational layer. Not as a replacement for developer workflow, but as the condition that makes developer workflow sustainable.

The testing gap in icon menus is real. The organizational gap is real. The procurement gap is where both of them originate. If your organization is still treating WCAG conformance as something you verify after a vendor delivers, you're already downstream of the decision that matters.