Icon Menu Liability: When Both Arguments Miss the Legal Exposure

The developer-versus-procurement debate over icon menu accessibility is intellectually honest. Both David's analysis and the structural procurement argument it responds to contain real truths. But the framing shared by both positions — who is responsible for fixing the problem — is not the framing that matters when a complaint lands at the Department of Justice (opens in new window) or a plaintiff's attorney files under Title III of the ADA.

The legal question is not who made the technical error. It is whether a public accommodation or covered entity failed to provide equal access to people with disabilities. That distinction changes everything about how organizations should prioritize their response.

What ADA Web Accessibility Litigation Actually Looks Like

ADA web accessibility litigation has been rising steadily. Federal court filings involving digital accessibility have numbered in the thousands annually in recent years, with the overwhelming majority targeting private-sector entities under Title III. The ADA National Network (opens in new window) documents that courts have increasingly found websites and digital interfaces to constitute places of public accommodation — a legal threshold that applies regardless of whether the inaccessible component came from a vendor or was hand-coded by an internal developer.

When a hamburger menu lacks proper ARIA attributes, has no visible focus indicator, and fails to announce state changes to screen readers, the user who cannot navigate that interface is excluded from content and services others access without friction. The organization operating the website is the named defendant. Not the vendor. Not the procurement officer. Not the front-end developer.

This is not a technicality. It reflects a foundational principle of disability rights law: the obligation to provide accessible services rests with the entity providing the service. As the DOJ's 2022 web accessibility guidance (opens in new window) makes explicit, covered entities cannot delegate their ADA obligations to third-party vendors and then disclaim responsibility when those vendors deliver inaccessible products.

The Governance Gap Both Arguments Underweight

What both sides of this debate underweight is the organizational accountability gap that sits between developer execution and procurement structure. At this publication, we track accessibility failures not just as technical or process problems but as governance failures — and governance failures carry the most concentrated legal exposure.

Consider the typical organizational chain for a navigation component failure. A vendor delivers an inaccessible hamburger menu. A developer integrates it without remediation. A QA process misses the WCAG violations. A content team populates it with unlabeled icons. A product manager ships it. Legal and compliance never reviewed the component. An accessibility audit, if it happened at all, occurred after launch.

Every node in that chain contributed to the failure. But under ADA enforcement, the organization is a single defendant. The internal attribution of blame — developer versus procurement — is legally irrelevant to the plaintiff and largely irrelevant to the DOJ. What matters is whether the organization had policies, processes, and oversight mechanisms that could have caught and corrected the failure before it excluded users.

As explored previously in this series, developer accountability is real and technically specific. But developer accountability without organizational governance structures to enforce it is not a compliance posture. It is individual heroism, and individual heroism does not scale or survive staff turnover.

WCAG Conformance Is a Legal Floor, Not a Technical Preference

One persistent problem in accessibility discourse is treating WCAG 2.1 (opens in new window) conformance as a technical best practice rather than what it has functionally become in litigation: the evidentiary standard against which accessibility failures are measured. When a plaintiff demonstrates that a navigation component fails Success Criterion 4.1.2 (Name, Role, Value) (opens in new window) — as an icon-only hamburger menu without proper ARIA labeling invariably does — they have established a concrete, documented failure against a published standard.

The Section 508 standards (opens in new window) for federal agencies incorporate WCAG 2.0 Level AA as a baseline, and federal contractors face overlapping obligations. For private-sector entities, WCAG conformance has become the de facto legal standard through its consistent use in DOJ settlement agreements and consent decrees.

This matters to the developer-versus-procurement argument because it reframes the stakes. The question is not primarily who should have caught the ARIA failure. The question is whether the organization can demonstrate a good-faith, systematic effort to meet an established accessibility standard. Procurement reform contributes to that demonstration. Developer training contributes to it. Neither alone constitutes it.

What a Risk-Centered Framework Demands

The correct organizational response to icon menu accessibility failures is not to resolve the developer-versus-procurement debate. It is to build the governance infrastructure that makes the debate moot.

That means written accessibility policies with named accountability. It means vendor contracts that include accessibility conformance requirements and audit rights, as recommended by the Great Lakes ADA Center (opens in new window) in its procurement guidance. It means internal QA processes with documented WCAG checkpoints. It means remediation timelines that are tracked and enforced. And it means legal review of accessibility posture as a routine compliance function, not a crisis response.

The Pacific ADA Center (opens in new window) has consistently documented that organizations with formal accessibility programs — regardless of whether they achieve perfect WCAG conformance — are substantially better positioned in enforcement contexts than organizations that treat accessibility as an informal developer responsibility. Documented effort matters. Governance structures matter. Internal blame assignment does not.

The Question Both Articles Are Missing

Building on this framework and the procurement analysis it engages, the more urgent question for organizations is not which team failed, but whether leadership understands that accessibility obligations are civil rights obligations with legal teeth. Icon menu failures are not primarily a developer problem or a procurement problem. They are a leadership problem — and leadership bears the liability.

When the DOJ investigates a web accessibility complaint, it is not auditing the competence of individual developers or the rigor of vendor selection criteria. It is assessing whether an organization made a genuine, documented, systematic effort to provide equal digital access to people with disabilities. Organizations with that infrastructure can demonstrate good faith even when specific components fail. Organizations without it are exposed regardless of how technically skilled their developers are or how carefully their procurement team evaluated vendors.

The accessibility community benefits from the technical specificity that both sides of this debate bring. But practitioners and organizational leaders need to understand the legal architecture that surrounds those technical conversations — because that architecture does not care who wrote the broken ARIA. The concrete next step is straightforward: if your organization cannot produce a written accessibility policy, a vendor contract with conformance requirements, and a documented QA process, you have a governance gap that no amount of developer skill or procurement diligence will close.