WCAG Passes. Screen Reader Fails. The Language Gap Nobody Fixed.

'Nobody told us screen readers didn't work on our checkout page,' the company's statement read. Nobody had to — they'd never asked.

That quote captures something precise about how accessibility and language access have been treated as parallel tracks that never quite meet. Organizations spend real resources getting to WCAG 2.1 Level AA (opens in new window) conformance. They fix contrast ratios, add skip links, label their form fields. Then they run a translation pass that touches only what a sighted reader sees — the headline, the paragraph text, the button label as it appears on screen. The ARIA label behind that button? Still in English. The error message that fires when the form fails validation? English. The alt text on the product image? English. The PDF application a user must download and complete to access a benefit? Inaccessible and English.

For a Spanish-speaking blind user navigating with a screen reader, that experience is not translated. It is fractured.

The Two Layers Most Translation Misses

Standard translation workflows — whether human, machine, or CMS-plugin — are built around visible text. They capture what renders in the viewport. That's the first layer, and it's the one that gets translated.

The second layer is the semantic layer: the meaning-bearing markup that assistive technology actually consumes. This includes:

• ARIA labels and roles — the programmatic name of an element, often different from its visible label
• Alt text — what a screen reader announces for every non-decorative image
• Form labels, placeholders, and validation messages — including the error strings that fire dynamically when a user makes a mistake
• Modal and tooltip content — often injected into the DOM after page load, invisible to static translation scrapers
• Table headers and structure — the semantic relationships that make data tables navigable
• lang attributes — which tell screen readers which language rules to apply when rendering text
• Live region and status messages — the dynamic announcements that tell screen reader users something has changed
• Link purpose — the accessible name of a link, which may differ entirely from its visible anchor text

A screen reader user navigating a translated page does not experience the visual layout. They navigate by this layer. If that layer is in English, the page is in English for them — regardless of what the visible text says.

The Third Layer: Documents

PDFs, Word forms, Excel spreadsheets, benefit applications, explanation of benefits notices, legal disclosures — these are simultaneously the content users most need to act on and the content least likely to have been translated or made accessible. An inaccessible, English-only PDF fails ADA Title II or Title III (opens in new window) and Section 508 (opens in new window) (disability access) while also failing Title VI of the Civil Rights Act (opens in new window) and Executive Order 13166 (opens in new window) (meaningful access for the 25 million-plus Limited English Proficient individuals in the United States) — simultaneously, in a single file.

These failures were designed in. Accessibility teams and localization teams have historically operated in separate silos, working from different standards documents, answering to different stakeholders. The result is a gap that neither team owns.

The Legal Landscape Is Dual, Not Single

This is where the compliance picture gets genuinely complex, and where the multi-standard compliance challenge becomes more than an organizational headache — it becomes a civil rights gap.

Legal Framework	Governing Standard	Who It Protects	What It Requires
ADA Title II	28 CFR Part 35 / WCAG 2.1 AA (2024 rule)	People with disabilities	Accessible digital content and documents
ADA Title III	28 CFR Part 36	People with disabilities	Accessible places of public accommodation, including digital
Section 508	36 CFR Part 1194 / WCAG 2.1 AA	People with disabilities (federal context)	Accessible electronic and information technology
Title VI, Civil Rights Act	42 U.S.C. § 2000d	Limited English Proficient individuals	Meaningful access to federally funded programs
Executive Order 13166	DOJ Guidance, August 2000	LEP individuals	Language access plans, translated vital documents

For organizations receiving federal funding — hospitals, universities, housing authorities, social service agencies — both columns of that table apply at once. A benefits application that is accessible but English-only fails Executive Order 13166. One that is translated but inaccessible fails the ADA. One that is neither fails both. The DOJ has been clear in its Title VI guidance (opens in new window) that vital documents must be translated for LEP populations meeting certain threshold criteria. The ADA's 2024 Title II rule makes WCAG 2.1 AA the enforceable standard for state and local government web content and mobile apps. Neither framework acknowledges the other. Organizations are left to reconcile them alone.

It's 2026, and most organizations are still treating these as two separate compliance programs.

What Closing the Gap Actually Looks Like

Idioma.chat (opens in new window) is a useful worked example precisely because it is built around the problem as described above — not just visible text, but the full accessibility layer. The technical scope matters here, so it's worth being specific.

Where a standard CMS translation plugin captures static rendered text, idioma.chat translates ARIA labels and roles as structured data, not as incidental string matches. Alt text is treated as a discrete content type with its own translation pass — meaning the description of an image is translated with awareness that it will be read aloud, not scanned visually. Form validation messages, which are typically injected dynamically by JavaScript after a user interaction, are captured and translated including their dynamic state — so a Spanish-speaking user who enters an invalid date doesn't receive an English error message telling them what went wrong.

Modal and tooltip content — the overlays and contextual help text that appear on user interaction — are handled as dynamic DOM content rather than as static page text. This matters because single-page application architectures and dynamically loaded content are exactly where conventional translation tools break down. The content doesn't exist in the initial HTML; it's assembled at runtime. Automated testing tools face the same limitation — they can only evaluate what's present at the moment of the scan.

The document layer is where the gap is sharpest. Idioma.chat addresses downloadable documents — PDFs, Word forms, policy notices — as a distinct content category, translating them while preserving or improving the structural accessibility that screen readers depend on: heading hierarchy, reading order, table structure, form field labels. A translated PDF that loses its tag structure in the conversion is not an accessible translated document. It's a translated image.

The lang attribute piece is easy to overlook but technically critical. When a screen reader encounters text, it uses the declared language to select the correct phonetic engine and pronunciation rules. A page with a Spanish lang attribute on the <html> element but untranslated ARIA labels creates a mismatch — the screen reader tries to pronounce English strings using Spanish phonology. The result is unintelligible. Idioma.chat handles language attribute propagation as part of the translation layer, not as an afterthought.

The Strategic Case for Designing These Together

Organizations that treat accessibility and language access as sequential projects — get WCAG right, then localize — are creating the exact gap described above. The semantic layer is built once, during development. Retrofitting translation onto it later means either re-opening the codebase or accepting the fractured experience described at the top of this piece.

The standards fragmentation problem that affects WCAG, Section 508, and EN 301 549 compliance is compounded here by the addition of a parallel legal framework (Title VI / Executive Order 13166) that most accessibility practitioners have not been trained to address. The practical answer is not to become an expert in both simultaneously — it is to use infrastructure that handles the intersection, so teams can focus on content quality rather than technical plumbing.

For organizations subject to both frameworks — and there are many — idioma.chat (opens in new window) represents a specific architectural answer to a specific architectural problem: that the accessibility layer and the language layer were never designed to be separate, and that serving users who rely on both requires treating them as one.

The Real Cost of the Gap

A site that passes WCAG 2.1 AA and only works in English has solved half the problem. The half it hasn't solved is the one where a blind Vietnamese-speaking user fills out a benefits application. That user exists. The gap is real. The tools to close it exist now.

The choice to leave the semantic layer in English is a choice to exclude users who rely on both accessibility and language access. It's not a technical limitation. It's a design decision.