WCAG Compliance Isn't Enough If Your Site Only Works in English

January 2021: the Biden administration reissues Executive Order 13166, reaffirming federal agencies' obligation to provide meaningful language access to limited English proficient populations. March 2023: the DOJ publishes updated Title II web accessibility guidance. Today: the average translated government website still serves Spanish-speaking screen reader users a patchwork of translated body copy and English ARIA labels, English error messages, and English-only PDF forms they're legally required to complete.

The compliance checkbox is green. The access gap is real.

The Two Layers Most Translation Misses

Here's the structural problem: most "translated" websites only translate what a sighted reader sees. The visible paragraph text, the navigation labels, maybe the headlines. What they don't translate are the two layers that actually determine whether a site is usable for someone who relies on both a screen reader and a language other than English.

Layer one: documents. PDFs, Word forms, benefit applications, policy notices, explanation of benefits letters, legal disclosures. These are simultaneously the least accessible and the least translated content that organizations publish. An English-only, untagged PDF benefits application fails ADA and Section 508 (opens in new window) on disability access grounds and Title VI and Executive Order 13166 (opens in new window) on language access grounds — at the same time, through the same document. Two civil rights frameworks, one failure point.

Layer two: the semantic layer. This is the meaning-bearing content that assistive technology actually consumes. WCAG 2.1 Success Criterion 4.1.2 (opens in new window) requires that interface components have names, roles, and values that can be programmatically determined. But "programmatically determined" doesn't mean "translated." A Spanish-speaking blind user navigating a form hears the translated field labels — if they're lucky — and then English validation errors when something goes wrong. The ARIA live regions announcing dynamic content updates? English. The alt text on informational images? English. The modal dialog explaining next steps? English.

The accessibility layer and the language layer were built in separate silos. That's the core problem.

What Full Semantic Translation Actually Requires

This is where idioma.chat (opens in new window) becomes a useful concrete example, because it illustrates what closing this gap actually looks like technically.

Traditional translation services — and most CMS translation plugins — operate on the visible DOM. They find text nodes, translate them, replace them. That workflow misses everything that lives in attributes rather than text content: aria-label, aria-describedby, title attributes, alt text, placeholder text, form legend elements, <caption> elements in data tables. It also misses content that doesn't exist in the initial page load — dynamically injected content in single-page applications, toast notifications, status messages announced via aria-live regions, error messages generated by JavaScript validation.

idioma.chat is designed to translate the full accessibility layer: ARIA labels and roles, alt text, form validation and error messages, modal and tooltip content, and dynamically loaded content in SPAs. For a screen reader user who reads in Vietnamese, this is the difference between a coherent navigable experience and a session where every error, every status update, and every button confirmation arrives in a language they don't read.

The WCAG 2.1 Success Criterion 3.1.1 (opens in new window) requires that the default human language of a page be programmatically determinable. SC 3.1.2 extends that to language of parts. These criteria exist so screen readers can switch pronunciation engines — so Vietnamese text is read with Vietnamese phonology, not English phonology applied to Vietnamese characters. A site that translates visible text but leaves ARIA labels in English creates a page where the language attribute says one thing and the assistive technology content says another. That's not a minor UX issue. It's a coherent failure of both standards.

The Legal Landscape Is Converging

Organizations navigating this space face what our research on standards fragmentation describes as compliance framework paralysis — multiple overlapping obligations that appear to be separate problems but are actually the same problem viewed through different legal lenses.

For Title II entities — state and local governments, public universities, transit authorities — 28 CFR Part 35 governs disability access, while Title VI of the Civil Rights Act and Executive Order 13166 govern language access. These are administered by different offices, audited on different timelines, and typically handled by different staff. The practical result is that the accessibility team builds WCAG-compliant interfaces and the translation vendor localizes visible text, and nobody owns the intersection.

For Title III entities — private businesses serving the public — the ADA's effective communication requirement means that auxiliary aids and services must actually convey the information. A translated website that leaves assistive technology content in English is not providing effective communication to a deaf-blind user who reads Braille output from a screen reader in Spanish.

The 25 million-plus limited English proficient people in the United States are not a niche edge case. They are a substantial portion of the population that many public-facing organizations are legally obligated to serve — and a population that is disproportionately likely to also need accessible digital interfaces.

What This Means for Practitioners

Access Layer	What Gets Missed	Governing Standard	Practical Test
Document accessibility	Untagged PDFs, English-only forms	ADA, Section 508, Title VI	Can a screen reader user complete the form in their language?
ARIA labels & roles	Button names, landmark labels	WCAG 2.1 SC 4.1.2	Switch browser to target language; tab through the interface
Alt text	Image descriptions	WCAG 2.1 SC 1.1.1	Inspect alt attributes in translated page state
Form errors	Validation messages	WCAG 2.1 SC 3.3.1, 3.3.3	Trigger errors in non-English session; what language fires?
Dynamic content	SPA updates, live regions	WCAG 2.1 SC 4.1.3	Use screen reader in target language; navigate dynamically loaded content
Language attributes	lang attribute on page and parts	WCAG 2.1 SC 3.1.1, 3.1.2	Inspect HTML lang attribute after translation renders

The testing methodology matters here too. Automated tools won't catch most of this. As our research on automated testing limits documents, automated tools detect at most 37% of accessibility barriers under comprehensive manual audit conditions. Language-layer failures in the semantic layer are almost entirely invisible to automated scanners — they require a human tester using a screen reader in the target language.

The Design Principle Organizations Need to Adopt

Language access and disability access need to be designed together, not handed off to separate vendors operating in separate silos. idioma.chat (opens in new window) is one example of infrastructure built on that principle — translating not just visible text but the full semantic and document layer that assistive technology depends on.

The practical starting point for any organization: audit what your current translation workflow actually touches. Pull up your translated site in a browser set to your target language. Open a screen reader. Tab through a form. Trigger a validation error. Navigate to a downloadable PDF. If any of those steps produces English output in a session that's supposed to be serving Spanish or Vietnamese speakers, you have found the gap.

A WCAG 2.1 AA audit that doesn't evaluate the translated state of the semantic layer is an incomplete audit. And a translation deployment that doesn't cover documents and ARIA content is not meaningful language access — it's visible-text localization with an access gap underneath.