Liability Is Settled. The Operational Question Isn't.

Patricia's analysis in Design System Blame Shifts Legal Exposure Back to You closes the liability question cleanly: ADA exposure sits with the domain operator, not the component library vendor. That's accurate, well-sourced, and practitioners need to internalize it. Where the analysis ends, though, is precisely where the operational challenge begins.

Knowing you own the liability doesn't tell you how to fix the system that keeps generating failures. And for most organizations — mid-size enterprises, state agencies, university systems — the gap between "we are legally responsible" and "we have the capacity to ensure compliance" is where accessibility programs actually collapse.

The Governance Gap Liability Framing Can't Close

The DOJ's March 2022 web accessibility guidance (opens in new window) is unambiguous about who bears responsibility. Patricia cites it correctly. But the same enforcement landscape that makes liability clear also reveals something about organizational capacity: most web accessibility complaints and consent decrees involve entities that understood they had obligations but lacked the internal infrastructure to meet them systematically.

This isn't a knowledge deficit. It's a structural one. When a design system propagates an inaccessible icon button pattern across 200 product surfaces — as Jamie's original analysis in Icon Button Failures Start in Design Systems, Not Code correctly diagnoses — the organization faces a remediation problem that legal clarity alone cannot solve. Who owns the fix? The design system team, if one exists? Individual product teams who implemented the component? Procurement, if the system came from a vendor?

The Section 508 program at the federal level (opens in new window) has spent years developing agency-level guidance on exactly this governance question, and federal agencies with dedicated accessibility programs still struggle with it. For organizations without that infrastructure baseline, "you own the liability" lands as true but operationally inert.

What Operational Capacity Actually Requires

Accessibility programs that survive contact with real product development cycles share structural features that liability framing tends to obscure. Research published by the Web Accessibility Initiative (opens in new window) identifies three prerequisites for sustainable accessibility: organizational policy, assigned roles with actual authority, and integration into development workflows. Awareness that compliance is required satisfies none of them.

Breaking that down into operational terms:

Governance with teeth. Design system teams need explicit accessibility ownership — not as a courtesy review step but as a blocking condition for component release. The WCAG 2.1 success criteria (opens in new window) for interactive controls, including the name, role, value requirements under 4.1.2, need to be embedded in the definition of done for any interactive component. Without that, the liability Patricia describes will keep materializing because the failure mode keeps shipping.

Audit cycles that close loops. Automated testing catches a meaningful but limited subset of accessibility failures. The WebAIM Million (opens in new window) findings that both Patricia and Jamie reference show persistent failures in landmarks and navigation — categories where automated detection rates are actually relatively high. The failures that automated tools miss, including many ARIA implementation errors on icon buttons, require manual review cycles with clear remediation ownership.

Vendor contract language. This is underemphasized across the field. If your design system comes from a third-party vendor, the contract should specify accessibility conformance requirements, testing documentation, and remediation timelines for reported failures. The Great Lakes ADA Center (opens in new window) and peer regional centers have published procurement guidance that covers this. You still own the liability — Patricia is right about that — but contract terms affect your remediation leverage and your ability to recover costs when vendor components generate compliance failures.

Training that reaches the implementation layer. Design system governance fails at the point where developers implement components in ways the system didn't anticipate. An icon button component with correct ARIA attributes can still fail if a developer wraps it in a way that suppresses the accessible name. The Pacific ADA Center (opens in new window) has documented this implementation drift pattern in training resources. Governance has to reach the people making those calls, not just the people building the components.

The Procurement Question the Field Hasn't Resolved

As explored in the original liability analysis, the vendor defense doesn't hold in ADA enforcement. But there's a related procurement question that the field hasn't fully worked through: what due diligence obligations exist before adopting a design system with known accessibility gaps?

Federal procurement under Section 508 has a structured answer — the Voluntary Product Accessibility Template (VPAT) (opens in new window) process creates at least a documented basis for evaluating vendor conformance claims. Private sector organizations operating under ADA Title III have no equivalent standardized requirement, which means accessibility evaluation of design systems before adoption is largely discretionary.

This matters because the remediation calculus changes significantly depending on when failures are identified. A design system adopted after accessibility evaluation that subsequently develops failures is a different operational situation than one adopted without evaluation. Neither changes the liability outcome Patricia describes, but they carry very different implications for remediation timelines, resource requirements, and internal accountability.

What Practitioners Should Do Next

The legal picture Patricia draws is the correct starting point. Organizations that haven't internalized ADA liability for their digital properties are operating with a significant blind spot, and that analysis needed to be made clearly.

But the practitioner's task doesn't end with understanding exposure. It requires building the operational capacity to close the gap between liability awareness and systematic compliance — governance structures, workflow integration, vendor accountability mechanisms, and training that reaches implementation. Not as aspirational program goals, but as concrete infrastructure investments that determine whether disabled users can actually access what your organization builds.

For accessibility professionals making the internal case for those investments, the liability framing Patricia provides is genuinely useful. "We own this legally" is a more tractable argument in budget conversations than "this is the right thing to do" — though both are true, and the second is the reason the first exists. The operational framework that follows — what it actually takes to meet that obligation systematically — is where the analytical work on our end needs to go next.

The design system root cause analysis is correct. The liability assignment is correct. The open question is whether organizations are building the capacity to act on both — and whether the people who can't access their products will have to wait for a consent decree to find out.