Your Site Passes WCAG. It's Still Not Accessible.

For a sighted English speaker, the government benefits portal works fine. The buttons are labeled, the forms are clear, the PDF application downloads in seconds. For a Vietnamese-speaking user who is blind, the same portal delivers translated body copy interrupted by English ARIA labels, English error messages, English alt text on every image, and a PDF application that exists only in English — a document they are legally required to complete. Two users. One portal. Completely different realities.

This is the access gap that the accessibility industry has largely failed to name clearly: a website can pass every WCAG 2.1 AA checkpoint and still be functionally inaccessible to tens of millions of people.

The Two Layers Nobody Translates

When organizations translate their websites, they almost universally translate one thing: the visible text a sighted reader sees on screen. Body copy, headlines, navigation labels — the surface layer. What gets left behind falls into two categories that matter enormously for users who rely on assistive technology.

The first is documents. PDFs, Word forms, Excel spreadsheets, policy notices, benefit applications, Explanations of Benefits, legal disclosures. These are simultaneously the least accessible content organizations publish and the least translated. A benefits application that exists only as an English PDF fails ADA and Section 508 (opens in new window) requirements for disability access and Title VI (opens in new window) and Executive Order 13166 (opens in new window) requirements for meaningful language access — two separate legal obligations, violated by a single document, at the same time.

The second is the semantic layer: the meaning-bearing content that assistive technology actually consumes. ARIA labels and roles. Alt text. Table headers. Form labels. Validation and error messages. Modal and tooltip content. Link purpose text. Status messages and live region announcements. Language attributes and metadata. Dynamically loaded content in single-page applications.

A screen reader user navigates by this layer, not by visual layout. When only the visible text is translated, a Spanish-speaking screen reader user hears translated paragraphs punctuated by English button labels, English form errors, and English alt text. The experience isn't just incomplete — it's actively confusing. The meaning falls apart exactly where the user needs it most.

Why This Keeps Happening

The reason is structural. Disability access and language access were built in separate silos. Accessibility teams work to WCAG conformance. Language access teams work to Title VI and EO 13166. Neither team typically owns the intersection. The result is organizations that can truthfully say they have an accessible website and a translated website, while serving a user who needs both simultaneously with something that is effectively neither.

Research on compliance framework fragmentation documents exactly this pattern: when multiple standards govern the same content, organizations tend to satisfy each standard in isolation rather than designing for the user who lives at the overlap. The LEP user who is also blind or low-vision doesn't appear in either compliance checklist as a named constituency.

The scale of the affected population is not marginal. The U.S. Census Bureau estimates more than 25 million people with limited English proficiency in the United States. Disability prevalence within that population tracks with national averages — meaning millions of people who need both translation and assistive technology support to use a given service. These are not edge cases. They are a predictable, identifiable user group that organizations are systematically failing.

What Closing the Gap Actually Looks Like

This is where idioma.chat (opens in new window) enters the analysis as a concrete, technical example of what full-layer translation requires. Most translation services — including machine translation pipelines bolted onto CMS platforms — operate on the DOM's visible text nodes. They stop there.

Closing the gap means translating the complete accessibility layer: ARIA labels and roles so screen readers announce controls correctly in the user's language, alt text so images carry meaning rather than silence, form validation and error messages so a user knows what went wrong and how to fix it, modal and tooltip content that doesn't revert to English when a screen reader focuses on it, and dynamically loaded content in single-page applications that updates in translation as the page state changes.

Documents require their own pipeline entirely. A translated, accessible PDF benefits application means the document is both tagged for assistive technology and carries its content in the user's language — not one or the other.

idioma.chat (opens in new window) is built around this complete translation model, addressing the semantic and document layers that traditional translation workflows miss. That technical specificity matters because the failure mode isn't usually bad intentions — it's a translation process that was never designed to reach the content assistive technology depends on.

The Legal Landscape Is Already There

Organizations sometimes treat language access and disability access as separate compliance tracks with separate timelines. The legal reality doesn't support that framing. Title III of the ADA, Section 508 for federal agencies and their recipients, Title VI of the Civil Rights Act, and Executive Order 13166 collectively cover the vast majority of organizations that serve the public. None of these frameworks carves out an exception for users who sit at the intersection of disability and limited English proficiency.

Research on standards fragmentation shows that organizations navigating multiple overlapping frameworks tend toward paralysis or toward satisfying each standard at its minimum threshold. Neither response serves the user. The practical path forward is designing for the most constrained user scenario — the person who needs both translation and assistive technology — and recognizing that meeting their needs satisfies the requirements of every framework simultaneously.

Automated testing won't catch this gap, either. Analysis of automated versus manual testing methodologies puts the maximum detection rate of automated tools at 37% of real accessibility barriers. A translated ARIA label that reads correctly in English but is never translated won't trigger a WCAG conformance failure in any scanner. It will fail the user completely.

What This Means Right Now

Organizations that serve linguistically diverse communities — government agencies, healthcare systems, financial institutions, legal services — should audit their translation scope against their accessibility layer. The question isn't only "is our site translated?" or "does our site pass WCAG?" It's: does the translation extend to every layer that a screen reader user encounters?

Start with documents. An English-only PDF application that LEP users are required to complete is a simultaneous failure under disability rights law and language access law. It's also the most concrete, auditable gap to close.

Then map the semantic layer. Pull a translated page and run a screen reader through it in the target language. What does the user actually hear? Where does the translation break down? The answer to that question is the real accessibility audit — not the WCAG conformance score.

A site that passes WCAG 2.1 AA is not fully accessible if it only works in English. That's not a critique of WCAG — it's a description of a gap the standard was never designed to close. Closing it requires treating language access and disability access as a single design problem, not two parallel compliance tracks. The users who need both have been waiting long enough.