The Translated Page That Screen Readers Can't Read

"The accessibility layer and the language layer were designed in separate silos."

That sentence, from the editorial brief behind idioma.chat (opens in new window), is one of the most precise descriptions of a systemic failure I've encountered in this field. Not because it's dramatic. Because it's so mundane. Two teams, two toolchains, two compliance checklists — and the person who gets left behind is a Vietnamese-speaking blind user hearing English error messages interrupt an otherwise translated page.

Two civil rights frameworks are operating in complete ignorance of each other. The people paying the price are among the most marginalized users in any digital ecosystem.

The Gap That Audits Don't Test

Here's the technical reality most accessibility programs miss: standard translation tools operate on visible DOM text. They scan what a sighted user would read on screen and translate that. For a sighted user with limited English proficiency, that can be sufficient.

For a blind or low-vision user relying on a screen reader, it is not.

Screen readers don't just read visible text. They announce ARIA labels and roles, alt text on images, live-region status messages, form validation errors, modal dialog content, and tooltip text. These elements live in the accessibility layer of a page — and they are almost universally untranslated, even on pages that have been through a full localization process.

The result is exactly what the idioma.chat brief describes: a user hears translated body copy interrupted by English button labels, English error messages, English alt text. The page is "translated" by every metric the organization tracks. The experience is incoherent for the person actually using it.

This is not a niche edge case. According to the U.S. Census Bureau (opens in new window), more than 25 million people in the United States have limited English proficiency. The National Federation of the Blind estimates that approximately 7.6 million Americans have a visual disability. These populations overlap. They have always overlapped. The assumption that language access and disability access serve separate, non-intersecting communities has never been accurate.

Two Legal Mandates, One Ignored Intersection

The legal framework here is worth naming precisely, because compliance programs tend to treat these as separate tracks.

Title III of the ADA (opens in new window) and Section 508 of the Rehabilitation Act (opens in new window) govern disability access to digital content. WCAG 2.1 Level AA is the operative technical standard. These frameworks have well-developed enforcement mechanisms, litigation history, and — for federally funded programs — audit infrastructure.

Title VI of the Civil Rights Act (opens in new window) and Executive Order 13166 (opens in new window) govern language access for programs receiving federal financial assistance. The standard is "meaningful access" — and that phrase carries weight. Meaningful access is not satisfied by translating only what a sighted user sees. If the error message that tells a user their form submission failed appears only in English, a screen reader user with LEP has not received meaningful access to that service. They've received a broken interaction in a language they don't understand.

These two frameworks are not in tension. They're complementary. But compliance programs almost never audit them together. WCAG audits don't test language. Language access reviews don't test the accessibility layer. The gap between them is where real people fall through.

Our research on multi-standard compliance challenges documents exactly this pattern — organizations pursuing conformance with individual standards while missing the intersectional failures that occur at their boundaries. The compliance framework paradox is that rigorous adherence to each standard in isolation can still produce an experience that fails users who sit at the intersection of multiple access needs.

What idioma.chat Actually Does Differently

idioma.chat (opens in new window) is the clearest operational example I've found of designing these two layers together rather than in sequence.

The distinction matters technically. Most translation infrastructure touches the visible DOM — the text nodes a sighted user reads. idioma.chat translates the full accessibility layer: ARIA labels and roles, alt text, form validation and error messages, modal and tooltip content, and dynamically injected content in single-page applications. That last category is particularly significant. SPAs load content asynchronously; a translation tool that only processes the initial DOM state will miss content that appears after user interaction. For a screen reader user, that means the dynamic content — often the most functionally critical content, like form responses and status updates — appears in the source language regardless of what language the rest of the page is in.

This is the technical gap that no WCAG audit catches, because WCAG doesn't test language. And it's the gap that no standard language access review catches, because those reviews don't test the accessibility tree. It requires an approach that treats both layers as part of a single coherent experience.

The Community Impact Is Specific

Abstract references to "the community" obscure what's actually happening to specific people. So let's be concrete about who carries the cost of this design failure.

Immigrant communities with higher rates of visual disability — including older adults, people with diabetes-related vision loss, and veterans — are disproportionately affected. Healthcare portals, benefits applications, and government service sites are exactly the high-stakes, high-complexity environments where language access and screen reader compatibility both matter most. A Somali-speaking screen reader user trying to navigate a Medicaid enrollment portal, a Cantonese-speaking blind user attempting to access Social Security information — these are not hypothetical users. They are people for whom a fractured accessibility-language experience is not an inconvenience but a barrier to essential services.

The Southeast ADA Center (opens in new window) has long documented the compounding barriers faced by communities at the intersection of disability and limited English proficiency. The pattern is consistent: when organizations design access in silos, intersectional users experience intersectional exclusion.

What Practitioners Should Do Next

If you're running an accessibility program, three specific questions should go on your next audit checklist.

First: Does your translation infrastructure touch ARIA attributes? Not just visible text — the aria-label, aria-describedby, role, and aria-live values that screen readers announce. If your translation vendor can't answer this question, the answer is no.

Second: Are form error messages and validation text translated? These are frequently injected dynamically and are among the most functionally critical content on any transactional page. Test them explicitly in your target languages with a screen reader.

Third: Does your language access review include assistive technology testing? If your LEP compliance review is conducted only by sighted reviewers, you are not testing the experience of blind or low-vision users with LEP. That's a gap in your methodology, not a gap in their need.

Our analysis of testing methodology limitations makes clear that automated tools catch at most 37% of accessibility barriers even within a single standard. Cross-standard intersectional failures like the language-accessibility gap are effectively invisible to automated testing. They require deliberate, human-centered evaluation that asks: who uses this, in what language, with what assistive technology?

The dominant model for accessibility compliance still treats disability access and language access as parallel tracks that never meet. They were never parallel. They were always the same road, and we've been leaving people stranded at the intersection.