Add a Translate Widget, Break Your Screen Reader: Why the Two Accessibility Fixes Cancel Each Other Out

Two reasonable decisions, made by two different people, eighteen months apart.

Someone added a translate widget to the site, because residents with limited English proficiency needed the content and a dropdown offering a hundred languages looked like an efficient answer. Someone else ran an accessibility audit and fixed the code, because the site had to conform to WCAG.

Both boxes are ticked. Each fix works in isolation. And a blind Spanish-speaking resident using a screen reader on the translated version of your page gets output that is close to unusable — not degraded, not awkward, but frequently impossible to follow.

This failure mode is invisible to everyone who is not in it. Sighted staff testing the widget see plausible Spanish. Screen-reader testing performed in English passes. Nobody tests the intersection, so nobody sees the intersection break.

Why does the combination break?

Because a screen reader does not read words. It reads words through a pronunciation engine, and it selects that engine from the language the page declares in its markup.

WCAG makes this explicit in two success criteria. 3.1.1 Language of Page (Level A) requires the default human language of the page to be programmatically determinable. 3.1.2 Language of Parts (Level AA) requires that any passage in a different language from the rest of the page be identified too. These exist precisely so assistive technology knows which pronunciation rules, voice profile and character mappings to apply.

Now consider what a client-side translation widget actually does. It replaces the visible text nodes in the document with translated strings. What it very often does not do is update the document’s declared language.

The result is a page that says, in its markup, “this is English”, containing text that is now Spanish, Vietnamese or Arabic. The screen reader believes the markup — it has nothing else to go on — and applies English pronunciation to Spanish words. The output is not accented Spanish. It is English phoneme rules forced onto Spanish orthography, and for a listener it lands somewhere between heavy distortion and noise. Vowels are wrong, stress is wrong, and words the listener knows perfectly well become unrecognisable.

For languages that do not use the Latin alphabet the failure is worse still. Applied to Arabic, Chinese or Russian text, an English voice profile may produce character-by-character readout, garbage, or silence.

What else breaks that nobody checks?

The language attribute is the headline failure. Several others travel with it.

Alt text is not always translated. Alternative text lives in an attribute, not in a visible text node. Depending on the widget and how it is configured, images may keep English alt text on an otherwise translated page. A sighted user sees a fully translated page; a screen-reader user gets translated prose interrupted by English descriptions. The same applies to ARIA labels, form field labels supplied by attribute, button accessible names, and the title text on links.

The widget’s own controls are often inaccessible. The language selector itself is frequently built as a styled div rather than a real control — unreachable by keyboard, unannounced, sometimes deliberately hidden from assistive technology with aria-hidden="true", which means a screen-reader user cannot discover that translation is available at all. The feature exists for everyone except the people using the other accessibility feature.

Dynamic content reverts. Content loaded after translation — search results, form validation messages, expanded accordions, live alerts — commonly appears in the original language, so the page becomes a mixture with no markup distinguishing the parts. This is exactly the condition 3.1.2 exists to prevent.

PDFs are untouched. This is the largest gap and the most consistently overlooked. A page-translation widget rewrites HTML. It does nothing whatsoever to a linked PDF. So a resident switches your site to Spanish, navigates confidently to the application form, and downloads an English document — untagged, very likely, as well as untranslated. Every genuinely important thing on a government site tends to be a PDF.

Reading order and structure are not translated concepts. Translated text expands and contracts — Spanish typically runs longer than English, and right-to-left languages such as Arabic need the document’s reading direction restructured, not merely its glyphs replaced. Arabic and RTL accessible PDFs covers what that involves.

Is the translation itself good enough for the people relying on it?

Separate question, and worth asking honestly, because the accessibility failure above sits on top of a quality question that exists regardless.

Machine translation has become genuinely good at gist. It remains unreliable at exactly the sentence types that dominate public-sector content: negation, conditionals, deadlines, eligibility rules, instructions, and legal or medical terminology. “You are not eligible unless you file by Friday” contains a negation, a conditional and a deadline in one sentence — three of the categories machine output most often inverts or drops.

The standard under Title VI of the Civil Rights Act is meaningful access. A translation that conveys the general topic but reverses an eligibility condition has not provided it. Title VI remains the correct authority here, unaffected by the revocation of the executive order that agencies once cited alongside it — we cover that change here — and separately, machine output is not accepted where a certified translation is required, which we cover in Google Translate and official documents.

None of this means a widget is worthless. For a resident skimming a news item to decide whether it concerns them, it is genuinely useful. The error is treating it as the language-access programme rather than as a convenience layered on top of one.

What should you actually do?

Tier your content honestly. Identify your vital documents — anything used to apply for, qualify for, or participate in a service, plus anything with legal or safety consequences. Those get human translation, published as real pages or real tagged documents in the target language, with the correct language declared in the markup. Everything else can reasonably sit behind a widget.

Publish translated content as first-class content. A real page with the correct language attribute on the document, correct markup on any passages in another language, translated alt text and translated form labels. This is the whole fix for the screen-reader problem: when the markup tells the truth, the pronunciation engine is correct and nothing else has to be worked around. The mechanics are in translated documents and WCAG language of parts.

Translate alt text as content, not as strings. Alternative text describes an image’s function in context. Run through a machine in isolation, it loses the context that made it meaningful. Our translated alt text post covers the difference.

Audit the widget’s own controls. Keyboard reachable, properly labelled, announced, not hidden from assistive technology. If residents who use screen readers cannot find the language selector, the feature does not exist for them.

Test the intersection, not the two halves. This is the recommendation that actually finds the problem. Have a native speaker who uses a screen reader read your translated pages. Not a sighted reviewer checking the Spanish, and not an English-speaking tester checking the screen reader — one person doing both at once. That single test surfaces nearly everything described in this post, and almost nobody runs it.

Fix the PDFs. Separately, deliberately, and in both dimensions: translated by a human and tagged for accessibility, as one workflow rather than two. Doing them in sequence means paying for the tagging twice, because translating a remediated file strips the structure it was given.

Have a translated site you have never tested with a screen reader? Send us the URLs, the languages you publish in, how translation is currently delivered (widget, separate pages, or a vendor portal), and a list of the PDFs residents actually download — then request a quote. We will test the intersection and tell you what a resident using both actually receives. Our document accessibility page covers how we produce translated and accessible documents as a single deliverable.