The Translation Gap Is a Procurement Failure, Not a WCAG Gap

The scenario David describes in his recent analysis is accurate and well-documented: a site achieves WCAG 2.1 AA conformance while a Vietnamese-speaking blind user hits an untranslated error message and has nowhere to go. The diagnosis is correct. But the prescription — implied throughout the accessibility community's response to this problem — tends to land in the wrong place.

The instinct is to look at WCAG and ask what it's missing. The more productive question is: why do agencies and vendors consistently ship multilingual implementations that treat semantic infrastructure as out of scope? That's not a standards gap. That's a procurement failure, a contract specification failure, and in many cases a vendor accountability failure that no revision to WCAG will fix.

What Procurement Documents Actually Say

The Section 508 standards (opens in new window) require federal agencies to ensure ICT is accessible. Title II of the ADA, as clarified by the DOJ's 2024 final rule (opens in new window), extends web accessibility requirements to state and local government entities. Neither framework specifies how language access and accessibility interact at the implementation layer — and that silence gets exploited every time a vendor scopes a contract.

When a state Medicaid agency issues an RFP for a benefits portal, the accessibility requirements typically reference WCAG 2.1 AA conformance. The language access requirements — if they exist at all — reference Executive Order 13166 and Title VI of the Civil Rights Act. These are treated as parallel workstreams managed by different teams, often different vendors, with no specification governing how they interact. The result is exactly what David's piece describes: a translated page with an untranslated ARIA layer.

This is an operational capacity problem, and it's worth understanding why our analytical framework at this publication treats operational capacity as the dimension where most accessibility failures actually originate. Technical standards exist. Legal obligations exist. The gap is in the organizational machinery that converts those obligations into shipped product.

Why Vendors Optimize for Audit Scope, Not User Outcomes

Accessibility audits — whether conducted by internal teams, third-party firms, or automated tools — check what they're scoped to check. A WCAG 2.1 AA audit run against an English-language baseline will pass a site that fails a Vietnamese-speaking blind user. This isn't a flaw in WCAG; it's a flaw in how audit scope gets defined in statements of work.

The Great Lakes ADA Center (opens in new window) and peer regional centers have documented repeatedly that technical compliance and functional access are not the same thing. Vendors know this. They also know that audit scope is negotiated, not fixed. When a contract specifies "WCAG 2.1 AA conformance" without specifying that conformance must be tested across all supported languages and all interface states — including error states, modal content, and live region announcements — vendors will optimize for the English-language audit pass.

This is rational vendor behavior in a broken procurement environment. It is not a problem that expanding WCAG's language access provisions would solve, because vendors would simply continue optimizing for whatever the audit scope covers.

The LEP-Disability Intersection Has Specific Operational Requirements

The population David identifies — people with limited English proficiency who also rely on assistive technology — sits at an intersection that requires specific operational planning, not just better technical standards. According to the U.S. Census Bureau's American Community Survey (opens in new window), over 25 million people in the United States speak English less than "very well." The disability community overlaps with this population in ways that compound access barriers at every layer.

Serving this population requires agencies to answer operational questions that no technical standard can answer for them: Which languages require full semantic layer translation, not just visible content translation? Who owns QA for ARIA labels in translated interface states? What is the escalation path when a screen reader user encounters an untranslated error message in a live production environment? How does the agency verify that a vendor's translation subcontractor has accessibility expertise?

These are staffing questions, vendor management questions, and quality assurance questions. As explored previously in this publication's analysis, the technical failure is real — but it is downstream of an organizational failure to specify, resource, and enforce the right requirements.

Where the DOJ Rule Creates Procurement Leverage

The DOJ's 2024 Title II final rule gives state and local government entities until April 2026 (for larger entities) to achieve conformance. This deadline creates procurement leverage that hasn't existed before. Agencies renegotiating or re-procuring web services contracts in the next 18 months have an opportunity to write language access and accessibility interaction requirements into contract specifications in ways that create enforceable vendor obligations.

The Pacific ADA Center (opens in new window) has published guidance on technical assistance for government entities navigating the new rule. The DOJ's ADA.gov resources (opens in new window) include implementation guidance that agencies can use to ground contract specifications in enforceable legal standards rather than aspirational best practices.

The specific contract language matters. "WCAG 2.1 AA conformance" is insufficient. Specifications should require conformance testing across all supported languages, all interface states, and all assistive technology combinations the agency has identified as relevant to its user population. They should require vendors to demonstrate that translation workflows include semantic layer content — ARIA labels, alt text, error messages, live region announcements — not just visible body copy.

Audit Scope Is the Lever

For organizations that have already shipped multilingual implementations and are now discovering the gap David describes, the most direct intervention isn't a WCAG revision — it's an audit scope revision. Commissioning an accessibility audit that tests the Vietnamese-language version of your benefits portal, in error states, with a screen reader, will surface failures that an English-language audit missed. That audit report then becomes the basis for vendor remediation conversations that have contractual teeth.

Our approach to accessibility analysis consistently finds that organizations with strong operational capacity — clear ownership, specified requirements, tested assumptions — achieve better functional access outcomes than organizations that rely on standards compliance as a proxy for user experience. WCAG conformance is a floor, not a ceiling, and the floor doesn't extend to the language access layer without explicit organizational effort to make it do so.

Building on the framework this publication has established for understanding where the technical and language layers fail to intersect, the next step for practitioners isn't to wait for WCAG 3.0 to address language access. It's to write better contracts, commission better audits, and hold vendors accountable for the full scope of what functional access requires — in every language your users speak.