WCAG Conformance Without Language Access Isn't Full Accessibility

A site that passes WCAG 2.1 AA but only works in English is not fully accessible to the communities it serves. That argument is no longer theoretical — it has a legal basis, a measurable population, and now a concrete technical model for what the fix actually looks like.

More than 25 million people in the United States have limited English proficiency (LEP) (opens in new window). Two separate legal regimes govern their access to digital services. The ADA and Section 508 (opens in new window) address disability access. Title VI of the Civil Rights Act of 1964 (opens in new window) and Executive Order 13166 (opens in new window) require federally funded programs to provide meaningful access to LEP individuals. These mandates are enforced by overlapping agencies and are almost never audited together. That gap is where millions of people fall through.

The Accessibility Layer Nobody Is Translating

Here is the structural failure: the content that is hardest to translate is exactly the content that assistive technology depends on.

Visible page text — the paragraphs, headings, and navigation labels a sighted English reader sees — is the easy part. Translation tools handle it routinely. What they miss is everything underneath: ARIA labels and roles, alt text, form validation messages, error text, modal and tooltip content, status messages, and dynamically loaded content in single-page applications. These are the strings that screen readers announce. They are the layer that makes a site usable for a blind or low-vision user.

When a Spanish-speaking screen reader user visits a site that has translated its visible text but left its accessibility layer in English, they encounter an English accessibility layer over translated visible content — or no translation at all. WCAG 2.1 Success Criterion 1.1.1 (Non-text Content) (opens in new window) requires that alt text convey equivalent information. If the user's language is Spanish and the alt text is in English, that criterion is technically met but functionally meaningless. The same logic applies to WCAG 2.5.3 (Label in Name), 4.1.3 (Status Messages), and the entire cluster of criteria that govern how assistive technology announces dynamic content.

This is not a fringe scenario. It is the default state of most multilingual sites.

What idioma.chat Actually Solves

idioma.chat (opens in new window) is the clearest worked example of what a real solution looks like at the technical layer. The distinction worth understanding precisely: idioma.chat translates the full accessibility layer, not just the static visible text.

That means ARIA labels and roles. Alt text. Form validation and error messages. Modal and tooltip content. Status messages. Dynamically loaded content in single-page applications — the category that breaks most translation approaches because the content doesn't exist in the DOM at page load.

This matters operationally because most organizations treating language access as a compliance checkbox are solving the wrong problem. They commission a translation of the marketing copy and consider the obligation met. The accessibility layer — invisible to a sighted non-screen-reader user — goes untouched. The result is a site that can pass an automated WCAG audit and still be functionally inaccessible to a blind Vietnamese speaker.

Our research on automated testing methodology found that automated tools detect at most 37% of accessibility barriers even within a single language. When you add the language-access dimension, the detection gap widens further: no standard automated accessibility testing tool currently checks whether ARIA labels are translated, whether error messages are in the user's language, or whether dynamically injected content is linguistically accessible. This is a category of failure that falls entirely outside current audit methodology.

The Legal Exposure Organizations Are Missing

The compliance picture here is more complex than most teams realize, and the fragmentation of overlapping standards creates real organizational paralysis. But the legal mandates are not ambiguous.

Title VI prohibits discrimination based on national origin in programs receiving federal financial assistance. The DOJ's guidance on language access (opens in new window) makes clear that failure to provide meaningful access to LEP individuals can constitute national origin discrimination. Executive Order 13166 extended that obligation to federal agencies directly and required them to develop language access plans. For state and local government programs receiving federal funding — which covers an enormous range of services from public health portals to court systems to benefits applications — both mandates apply simultaneously with ADA Title II obligations.

What this means in practice: a public benefits portal that achieves WCAG 2.1 AA conformance but provides no language access is potentially violating Title VI and Executive Order 13166 even if it is fully ADA-compliant. These are separate legal obligations enforced by separate mechanisms. The DOJ's Civil Rights Division, the Department of Health and Human Services Office for Civil Rights, and individual federal funding agencies all have enforcement authority over language access. Unlike ADA litigation, language access enforcement often comes through federal funding investigations rather than private lawsuits — which means the exposure can be institutional rather than case-by-case.

| Legal Framework | Governing Authority | Who It Covers | What It Requires | Enforcement Mechanism | |---|---|---|---|---| | ADA Title II | 28 CFR Part 35 | State & local government | Disability access to programs and services | DOJ, private litigation | | ADA Title III | 28 CFR Part 36 | Places of public accommodation | Disability access to goods and services | DOJ, private litigation | | Section 508 | 36 CFR Part 1194 | Federal agencies | Accessible electronic and information technology | GSA, agency-level enforcement | | Title VI, Civil Rights Act | 42 U.S.C. § 2000d | Recipients of federal financial assistance | No national origin discrimination | DOJ, federal funding agencies | | Executive Order 13166 | Federal Register Vol. 65 | Federal agencies + recipients | Meaningful access for LEP individuals | DOJ coordination, agency plans |

The Architectural Problem Underneath the Legal One

The deeper issue is structural. Disability access and language access have been treated as separate workstreams by separate teams using separate tools — and that separation produces the failure mode described above. When an accessibility team audits a site, they test WCAG conformance in English. When a localization team translates a site, they export visible text strings and translate them. Neither team is looking at the intersection.

The question worth sitting with: what does it mean for the field when our entire audit methodology assumes a single-language user? Every WCAG success criterion, every automated testing tool, every manual audit checklist is implicitly written for a user who reads the dominant language of the interface. The standards framework itself has gaps that make this intersection nearly invisible to practitioners working within any single framework.

idioma.chat represents a design choice that refuses that separation — treating the accessibility layer and the language layer as a single problem that must be solved together. That is not just a product decision. It is an argument about what accessibility actually means when the community you serve is linguistically diverse.

What Practitioners Should Do Now

The operational path forward requires treating language access as part of the accessibility audit scope, not a separate workstream. Concretely:

• Audit your ARIA strings separately. Export all ARIA labels, roles, and descriptions from your codebase. Ask whether these strings are included in your translation pipeline. In most cases, they are not.
• Test error messages in target languages. Trigger form validation errors with your screen reader set to the language of your LEP user population. What does it announce? Is it translated?
• Audit dynamic content. Single-page applications that load content after page render are the hardest case. Test whether injected content — including status messages governed by WCAG 4.1.3 (opens in new window) — is translated when it appears.
• Map your federal funding. If your organization receives federal financial assistance, Title VI and Executive Order 13166 apply. Identify which programs are covered and whether language access plans exist.
• Review idioma.chat's approach (opens in new window) as a technical reference. Whether or not you adopt the tool, the architecture it describes — full-layer translation including the accessibility layer — is the right specification for what a solution needs to accomplish.

The communities most likely to need public digital services — benefits portals, health systems, court access, housing applications — are also the communities most likely to include both LEP individuals and disabled people. Designing for that intersection is not a compliance edge case. It is designing for the actual population. The legal mandates exist because equal participation is the baseline, not the aspiration.