Design System Blame Shifts Legal Exposure Back to You

When icon button failures appear in audits, the instinct is to trace them upstream to design systems. That's analytically sound — but legally irrelevant. Courts and enforcement agencies don't adjudicate component library provenance. They adjudicate whether your website excludes disabled users, and the organization whose name is on the domain bears that liability regardless of where the broken component originated.

Jamie's analysis in Icon Button Failures Start in Design Systems, Not Code makes a structurally correct argument about systemic root causes. Design systems do propagate failures at scale. The WebAIM Million data does show persistent landmark and navigation failures across production sites. The diagnosis is accurate. What the framing underweights is the risk calculus that organizations actually face when those failures surface in litigation or DOJ enforcement actions — and that calculus doesn't care where the bug originated.

The Vendor Defense Doesn't Hold in ADA Enforcement

The Americans with Disabilities Act (opens in new window) places the compliance obligation on the entity operating the place of public accommodation — or, under Title II, the government entity providing the service. There is no statutory carve-out for "we used a third-party component library." The DOJ's web accessibility guidance (opens in new window) issued in March 2022 is explicit that covered entities are responsible for the accessibility of their digital services, full stop.

This mirrors the pattern in physical accessibility. A retailer can't defend an inaccessible entrance by pointing to the contractor who installed it. The operational responsibility sits with the entity controlling the space. Digital environments follow the same logic, and the volume of web accessibility litigation over the past five years has reinforced it consistently. According to data tracked by accessibility law firm Seyfarth Shaw, federal web accessibility lawsuit filings have remained in the thousands annually since 2018, with no meaningful reduction despite growing industry awareness of design system problems.

Organizations that have absorbed the "it's a design system problem" framing without coupling it to a remediation accountability structure are carrying undisclosed legal exposure. The root cause analysis is useful for fixing the problem. It is not a shield against the consequences of the problem existing — and more directly, it is not a defense against the harm that screen reader users and keyboard-only navigators experience when those failures reach production.

What Automated Testing Actually Catches — and What It Doesn't

Jamie's piece references automated testing methodology as part of the gap analysis. This deserves harder scrutiny from a risk perspective. WCAG 2.1 (opens in new window) success criteria — including the Level A failures documented in the original audit of icon button menu patterns — are not uniformly detectable by automated tools. Research from Deque's axe-core project (opens in new window) and independent evaluations consistently show that automated tools catch somewhere between 30 and 40 percent of WCAG issues. The rest require manual testing or assistive technology verification.

This matters because organizations often use automated CI/CD integration as their primary accessibility gate. If a design system ships a hamburger menu without aria-expanded state management or proper landmark structure, and your automated pipeline doesn't flag it, the failure propagates to production with a false compliance signal attached. You've passed your internal check. You've still shipped a WCAG Level A violation. And when a screen reader user files a complaint or a plaintiff's attorney runs a manual audit, the automated test results don't constitute a defense.

As explored in the original analysis, these failures cluster — missing <nav> landmarks, absent ARIA state announcements, no banner region appearing together. That clustering is precisely what manual auditing catches that automated tools miss. Organizations relying on design system vendors to handle this, without independent verification, are outsourcing a legal obligation they cannot actually transfer.

The Procurement Step Organizations Consistently Skip

The Section 508 framework (opens in new window) for federal procurement offers a model that private sector organizations rarely apply. Federal agencies are required to evaluate the accessibility of ICT products before procurement, using Accessibility Conformance Reports based on the VPAT template. The underlying logic — assess accessibility before you integrate a component, not after users file complaints — is sound regardless of whether Section 508 applies to your organization.

Private sector organizations pulling from open-source component libraries or purchasing UI frameworks rarely conduct this evaluation. They inherit whatever the library ships, discover failures in audits or litigation, and then trace the root cause upstream in the way Jamie's analysis describes. The sequence is backwards from a risk management perspective. The ADA National Network's guidance on digital accessibility (opens in new window) consistently emphasizes proactive assessment over reactive remediation, and the cost differential between those two approaches is substantial.

Our editorial approach at this publication — detailed at /about#approach — prioritizes the risk and legal dimensions of accessibility failures precisely because the field has an abundance of technical analysis and a shortage of honest accounting for organizational liability. Understanding that design systems are the root cause is step one. Building procurement criteria, vendor contracts with accessibility warranties, and independent verification into your workflow is the step that actually reduces exposure.

Shared Responsibility Structures That Actually Work

None of this is an argument against Jamie's systemic diagnosis. Design systems propagating broken patterns is a real and significant problem, and fixing it upstream is more efficient than auditing every downstream implementation. The argument is against treating the systemic explanation as a substitute for organizational accountability — and against losing sight of who is actually harmed when those failures ship.

Practical risk reduction requires both tracks running simultaneously. On the upstream track: evaluate component libraries before adoption, require VPAT documentation from vendors, include accessibility acceptance criteria in design system contribution guidelines. The Pacific ADA Center (opens in new window) and other regional ADA centers publish technical assistance resources that can inform these criteria without requiring organizations to develop them from scratch.

On the downstream track: maintain independent manual testing that doesn't rely on design system vendors' self-assessment, establish clear internal ownership for accessibility failures regardless of their origin, and build remediation timelines that don't wait for upstream fixes that may never arrive on your schedule.

Building on this framework for understanding design system failures, the question organizations should be asking isn't only "why do these failures reproduce at scale" — it's "who in our organization is accountable when they do, and what's our documented remediation process." Root cause analysis without that accountability structure is intellectually satisfying and operationally insufficient.

The icon button failures in the original audit are Level A violations — the baseline of WCAG conformance. They are not edge cases or advanced requirements. When those failures appear on a production site, the design system that shipped them is a contributing factor. The organization operating the site is the liable party. Both things are true simultaneously, and risk-mature accessibility programs treat them that way. The practical next step is concrete: before your next component library update ships to production, confirm that your manual testing process — not your CI pipeline — has signed off on landmark structure and ARIA state behavior independently of whatever the vendor's documentation claims.