WCAG Compliance Isn't Enough If Your Site Only Speaks English

There are no translated ARIA labels on most "multilingual" government websites. The alt text is in English. The form error messages are in English. The modal dialogs — the ones that announce critical information to screen reader users — are in English. The visible body copy has been translated. The accessibility layer has not.

For a sighted user, that's an incomplete experience. For a blind Vietnamese-speaking user relying on a screen reader, it's something closer to exclusion.

This is the gap that most organizations haven't named yet: a website can achieve full WCAG 2.1 AA conformance (opens in new window) and still deliver a fractured, inaccessible experience to users who need both disability access and language access simultaneously. These two obligations have been designed in separate silos — technical accessibility in one team, translation in another — and the people caught between them are among the most underserved users on the web.

The Fracture Point

Here's what actually happens when a screen reader user navigates a "translated" page built with conventional tools: the body copy announces in Vietnamese. Then a button label announces in English. Then a form validation error announces in English. Then an ARIA live region status update — the kind that tells a user their form was submitted successfully — announces in English.

Conventional translation pipelines operate on the visible DOM. They parse what a sighted user sees and translate that. But screen readers don't only consume visible text. They consume ARIA attributes (opens in new window) — aria-label, aria-describedby, role announcements, aria-live regions — along with alt text on images, placeholder text in form fields, and error messages injected dynamically by JavaScript. None of those are "visible" in the traditional sense. Most translation tools never touch them.

The result is a user experience that is simultaneously WCAG-compliant and linguistically inaccessible. That's not a contradiction — it's a design failure baked into how we've separated these disciplines.

Two Legal Frameworks, One User

The legal landscape involves two distinct but overlapping obligations that most organizations haven't mapped together.

The first is disability access. The Americans with Disabilities Act (opens in new window) and Section 508 of the Rehabilitation Act (opens in new window) require that digital content be accessible to people with disabilities. WCAG 2.1 AA is the operative technical standard for most covered entities.

The second is language access. Title VI of the Civil Rights Act (opens in new window) prohibits discrimination based on national origin by entities receiving federal funding. Executive Order 13166 (opens in new window) extended that obligation, requiring federal agencies and their recipients to provide meaningful access to limited English proficient (LEP) individuals. The DOJ's LEP guidance (opens in new window) is explicit: "meaningful access" is not satisfied by partial translation.

Here's the compliance gap hiding in plain sight: an organization can satisfy its WCAG auditors and its translation vendor simultaneously, and still fail both legal frameworks for a screen reader user who speaks a language other than English. The WCAG audit doesn't test whether ARIA labels are translated. The translation vendor doesn't touch the accessibility layer. Nobody owns the intersection.

Legal Framework	Primary Obligation	Technical Scope	Who It Covers
ADA / Section 508	Equal access for people with disabilities	Full DOM including ARIA, alt text, dynamic content	Disabled users
Title VI / EO 13166	Meaningful access for LEP individuals	All content necessary for program participation	Limited English proficient users
Combined obligation	Equal access for disabled LEP users	Accessibility layer in the user's language	Screen reader users who are not English-proficient

This isn't an edge case. The U.S. Census Bureau reports (opens in new window) that over 25 million people in the United States are limited English proficient. Disability prevalence among LEP communities tracks with general population rates. The intersection is large, and it's been systematically overlooked.

What Closing the Gap Actually Looks Like

Idioma.chat (opens in new window) is the clearest working example of what it means to treat these two obligations as one design problem rather than two separate checklists. The platform translates not just visible body copy but the full accessibility layer: ARIA labels and roles, alt text on images, form validation and error messages, modal and tooltip content, and dynamically injected content in single-page applications.

That last category — dynamically loaded content — is where conventional translation tools fail most completely. Modern web applications don't serve a static HTML page. They inject content after load via JavaScript, update ARIA live regions in response to user actions, and render error messages on the fly. A translation pass that runs at page load misses all of it. A screen reader user submitting a form in a translated SPA may hear the field labels in their language and the error feedback in English.

Idioma.chat addresses this at the infrastructure level, intercepting dynamic content updates and translating the accessibility attributes alongside the visible text. The experience is coherent — same language throughout the visible interface and the assistive technology layer.

This matters for organizations navigating the compliance framework paradox that emerges when multiple standards apply simultaneously. The instinct is to satisfy each standard separately. The better approach is to identify the user whose needs sit at the intersection of all of them — and design for that user first.

The Hardest Content to Translate Is What Assistive Technology Depends On

There's a technical irony worth naming directly: the content most critical to screen reader users is exactly the content hardest to reach with conventional translation tools.

Alt text lives in an HTML attribute, not in the visible page. ARIA labels are often set programmatically, not written into static markup. Error messages are frequently generated by JavaScript frameworks at runtime. Live region announcements happen in response to events. None of this is visible in the browser in the way that a paragraph of body copy is visible.

This is also the content that automated testing tools miss most reliably. Automated WCAG scanners check whether alt text exists — not whether it's been translated. They verify that ARIA labels are present — not whether they're in the user's language. The gap is invisible to the tools most organizations rely on to confirm compliance.

Manual audits catch more, but only if the auditor is testing in the target language with a screen reader. Most aren't. The result is that organizations receive clean audit reports and remain genuinely unaware that their Vietnamese-speaking blind users are hearing a bilingual jumble on every form submission.

What Organizations Should Do Now

Treating language access and disability access as a single design requirement from the start — not as sequential checklists — is the practical path forward.

For organizations subject to both ADA/Section 508 and Title VI/EO 13166 obligations (which includes most government agencies, universities, and federally funded programs), the specific steps are:

Audit what your translation tools actually translate. Test your translated pages with a screen reader set to the target language. Listen for English interruptions in button labels, error messages, and status announcements. This is a manual test — automated tools won't find it.

Inventory your dynamic content. Identify every place your application injects content after page load: form validation, modal dialogs, toast notifications, ARIA live region updates. These are your highest-risk gaps under both frameworks.

Evaluate translation infrastructure against the full DOM. Ask your translation vendor specifically whether they translate aria-label, aria-describedby, alt, placeholder, and dynamically injected text nodes. If they can't answer that question precisely, the answer is probably no. Idioma.chat (opens in new window) provides a concrete benchmark for what full-layer translation looks like.

Map your legal exposure across both frameworks. Title VI "meaningful access" is not a vague standard — DOJ guidance specifies that LEP individuals must be able to participate in programs and services on a basis comparable to English speakers. A screen reader user who can't navigate your application because error messages are in English is not receiving meaningful access, regardless of your WCAG conformance score.

The standards fragmentation problem in accessibility compliance is real — organizations face overlapping obligations that don't always point in the same direction. But this particular gap points in exactly one direction. The user who is both disabled and limited English proficient needs both layers translated. That's not a compliance edge case. It's a design requirement that the field has been slow to name.

Name it now. Then fix it.