The Developer Isn't Off the Hook: Why Procurement Reform Alone Won't Fix Icon Menus

Procurement reform is a legitimate lever for accessibility change. Jamie's recent analysis makes a compelling structural argument: when vendor selection processes don't include accessibility requirements, the failures that follow are baked in before a single developer writes a line of code. That framing is accurate as far as it goes.

But structural arguments carry a risk. They can inadvertently redistribute accountability so completely that the people with the most direct technical leverage — developers, QA engineers, front-end architects — start treating accessibility failures as someone else's problem to solve upstream. That's not a hypothetical. It's a pattern that plays out across newsrooms, government digital teams, and enterprise UX shops. The procurement problem is real. The developer accountability problem is also real. Treating them as mutually exclusive is where the analysis breaks down.

What Developers Actually Control

Start with the technical reality. A vendor ships a hamburger menu component. That component has a button element, or it doesn't. It has an aria-expanded attribute that updates state, or it doesn't. It has a visible focus indicator that meets WCAG 2.1 Success Criterion 2.4.7 (opens in new window), or it doesn't. The procurement officer didn't make those choices. A developer did.

When an internal team inherits a vendor component, they rarely deploy it without modification. Theming, integration, content population, responsive behavior adjustments — these touchpoints are all opportunities where a developer can catch and correct an accessibility failure, or miss it entirely. The WebAIM Million annual report (opens in new window) consistently finds that the most common WCAG failures — low contrast, missing form labels, empty buttons — are exactly the kind of implementation-level errors that survive vendor handoff and developer integration alike.

An empty button element on a hamburger menu icon isn't a procurement failure in isolation. It's a failure that procurement didn't prevent and development didn't catch. Both links in that chain matter.

The VPAT Verification Problem Cuts Both Ways

Jamie's piece correctly identifies that Accessibility Conformance Reports based on GSA's VPAT framework (opens in new window) are largely unverifiable at point of purchase. Federal agencies are required to review them; most state and local governments aren't. Self-attestation from vendors is the norm, and it's often optimistic.

Here's the part that gets less attention: developers are frequently the only people in an organization technically equipped to verify those claims after purchase. A procurement officer can't open a screen reader and navigate a trial instance of a CMS. A developer can. The Section 508 ICT Testing Baseline (opens in new window) provides a standardized methodology that any competent front-end developer can apply. It's not exotic knowledge.

When developers don't perform that verification — because they lack the time, the mandate, or the awareness — the unverified VPAT claim becomes the operational reality. The structural failure of procurement and the individual failure of technical review compound each other. Fixing procurement without building developer verification capacity doesn't close the loop.

The Inherited Component Myth

There's a narrative convenience in the "we inherited this component" framing that deserves scrutiny. As explored in the companion piece, hamburger menu failures are often systemic across vendor platforms. But systemic doesn't mean immutable.

The ARIA Authoring Practices Guide (opens in new window) from the W3C provides clear, implementable patterns for disclosure navigation — the interaction model underlying most hamburger menus. These patterns are free, well-documented, and don't require a procurement cycle to implement. A developer who knows that a vendor component fails the disclosure navigation pattern has the technical knowledge to patch it, wrap it, or flag it for replacement.

The question isn't whether developers have the technical capacity to address these failures. Most senior front-end developers do. The question is whether they're given the organizational mandate and the time to exercise it. That's a management and culture problem — distinct from both the procurement problem and the pure technical problem, and one that sits squarely within development team leadership's sphere of influence.

This is the dimension that gets flattened when analysis focuses exclusively on structural procurement reform. You can overhaul your vendor selection criteria and still ship inaccessible hamburger menus if your development culture treats accessibility as a compliance checkbox rather than a quality standard — and a baseline obligation to the people who depend on keyboard navigation and screen readers to use your product at all. The Nielsen Norman Group's research on accessibility in agile teams (opens in new window) has documented this pattern repeatedly: process improvements at the organizational level don't automatically translate to practice changes at the team level.

Where Procurement Reform Helps — and Where It Doesn't

To be clear: this isn't a dismissal of the procurement argument. Requiring vendors to submit independently audited ACRs rather than self-attestations, building accessibility requirements into contract language with enforceable remediation timelines, and including disabled users in vendor evaluation panels — these are meaningful interventions. The ADA National Network (opens in new window) has published guidance on procurement practices that embed these requirements, and organizations that follow them do see better baseline outcomes.

But procurement reform operates on a cycle measured in years. Enterprise CMS contracts run three to seven years. Design system licenses get renewed with minimal re-evaluation. The hamburger menu that failed accessibility review in 2021 is often still in production in 2025, waiting for the next procurement cycle to create an off-ramp.

Developers don't have to wait for that cycle. They can audit the component today. They can file an internal accessibility bug today. They can refuse to ship a release with an empty button element today — or at minimum, document the failure so it's visible to the people who do have procurement authority.

A Balanced Accountability Framework

Building on the procurement-centered framework, the more complete picture looks like this: procurement reform sets the floor; development practice determines whether you stay on the floor or build above it.

Organizations that achieve durable accessibility outcomes — the kind that survive personnel changes, vendor transitions, and platform migrations — tend to have both. They have procurement processes that require verifiable accessibility evidence, and they have development cultures where accessibility review is a non-negotiable part of the definition of done. The DOJ's updated ADA web accessibility guidance (opens in new window) doesn't distinguish between procurement failures and implementation failures when assessing organizational liability. Enforcement agencies look at outcomes, not process diagrams.

For practitioners: if you're a developer who has been waiting for your organization's procurement process to fix the hamburger menu problem, that's a reasonable long-term strategy and an inadequate short-term one. The approach we take at this publication is to hold multiple accountability points simultaneously rather than locating failure in a single structural layer.

Icon menu failures are a procurement problem. They're also a development problem. The people most equipped to fix them in the short term are developers. The people most equipped to prevent them at scale are procurement officers. Both groups need to be in the room, and both groups need to own the outcome — because the screen reader user navigating your site today can't wait for the next contract cycle.