WCAG Passes, But Who Can Read It?

25 million. That's the number of people in the United States living with limited English proficiency — a population larger than the state of Texas, navigating digital services built almost entirely in English. Meanwhile, the accessibility field has spent two decades refining WCAG conformance checklists, automated scanners, and remediation workflows. The result: websites that screen readers can traverse with reasonable confidence, but only if the user's primary language happens to be English.

This is the language access gap, and it sits at the center of an underexplored civil rights failure. A site that achieves WCAG 2.1 AA conformance but operates exclusively in English has not achieved full accessibility. It has achieved accessibility for a subset of the people it serves. The distinction matters — legally, ethically, and practically.

Two Legal Regimes, One Invisible Gap

The legal architecture here is genuinely complex. The ADA and Section 508 (opens in new window) govern 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 are separate mandates, enforced by overlapping agencies, and — this is the critical failure — almost never audited together.

Organizations pursuing multi-standard compliance already struggle with fragmented requirements across WCAG, Section 508, and state regulations. Adding language access to that picture doesn't just add a checkbox — it reveals a structural blind spot in how accessibility programs are designed. Most compliance teams are built around disability access frameworks. Language access expertise lives somewhere else in the organization, if it lives there at all. The two streams rarely meet.

The enforcement gap compounds this. A WCAG audit tests whether a screen reader can navigate the page. It does not test whether the content that screen reader announces is in the user's language. Those are different questions, and the second one almost never gets asked.

The Technical Problem Nobody Is Talking About

When organizations do invest in translation, they typically translate visible page text — the paragraphs, headings, and button labels a sighted user reads. That's the easy part.

The hard part is the accessibility layer itself.

ARIA labels and roles. Alt text on images. Form validation and error messages. Modal and tooltip content. Status messages. Dynamically loaded content in single-page applications. This is the infrastructure that assistive technology depends on. And in the overwhelming majority of translated sites, this layer remains entirely in English.

The practical consequence: a screen reader user who speaks Spanish or Vietnamese encounters translated visible text wrapped in an English accessibility layer. The page looks accessible. The automated audit passes. But the user experience is fragmented at precisely the moments when clarity matters most — error recovery, form completion, navigation landmarks, alert messages. These are not cosmetic failures. They are functional barriers.

This is why idioma.chat (opens in new window) represents a meaningfully different technical approach. Rather than translating only the static visible text, idioma.chat addresses the full accessibility layer: ARIA labels and roles, alt text, form validation messages, modal and tooltip content, and dynamically loaded content in single-page applications. The distinction between translating a page and translating the accessibility infrastructure of a page is not subtle — it's the difference between a site that appears multilingual and one that actually functions multilingually for users who depend on assistive technology.

This connects directly to a pattern documented in our research on automated testing limitations: automated tools detect, at best, 37% of accessibility barriers even within a single language. Add a second language and the detection gap widens further, because no standard audit protocol tests whether ARIA labels translate correctly or whether error messages render in the user's language.

Who Bears the Cost of This Gap

The populations most affected by this failure are not abstract. Spanish speakers represent the largest LEP community in the United States, but Vietnamese, Chinese, Korean, Tagalog, and Arabic speakers collectively number in the millions. Within each of these communities, the intersection with disability is not hypothetical — disability rates do not disappear at language boundaries.

Federally funded healthcare portals, benefits systems, and public health platforms are exactly the services where this intersection is most consequential. A person navigating a Medicaid portal in Spanish who uses a screen reader is not served by a site that passes WCAG in English. They are served by a site that passes WCAG in English and provides a complete, functional accessibility layer in Spanish. Those are not the same thing.

The Southeast ADA Center (opens in new window) has long emphasized that community engagement must precede technical solutions — that understanding who is actually trying to use a service shapes what accessibility means in practice. The language access gap is a direct consequence of skipping that step. Programs are built for the disability community as imagined by compliance teams, not the disability community as it actually exists across linguistic lines.

What Organizations Need to Do Differently

Closing this gap requires treating language access and disability access as a single design problem, not two separate workstreams.

Concretely, that means:

• Audit the accessibility layer, not just the visible text. When conducting multilingual testing, verify that ARIA labels, alt text, error messages, and dynamic content render correctly in each supported language. Standard WCAG audits — automated or manual — do not test this by default.
• Evaluate translation infrastructure for accessibility completeness. Most translation management systems and machine translation APIs operate on visible DOM text. Verify whether your current solution captures ARIA attributes, form validation strings, and dynamically injected content. Tools like idioma.chat (opens in new window) are specifically designed to address this gap.
• Map your LEP population before scoping your language access plan. Title VI and EO 13166 require a four-factor analysis to determine which languages a program must support. That analysis should inform which languages your accessibility layer must also support — not just your visible content.
• Integrate compliance streams at the policy level. Language access plans and digital accessibility plans should be developed together, reviewed together, and updated together. The communities they serve overlap significantly.

A site that passes WCAG 2.1 AA but delivers an English-only accessibility layer to a multilingual user base has not closed its accessibility gap. It has documented it. The standards exist. The legal mandates exist. The technical solutions, including idioma.chat's approach to full-layer translation (opens in new window), exist. What's been missing is the recognition that these two access obligations were always the same obligation — equal participation, for everyone who shows up.