Compliance

Your Translated Documents Are Probably Failing WCAG — Here Is Why

If your agency translates public-facing documents, you have almost certainly done the right thing for the wrong outcome: you paid for translation so that a Spanish-speaking resident could use your form, and the file you published cannot be read aloud in Spanish.

This is not a translation quality problem. It is a tagging problem, and it is invisible unless you test with a screen reader — which is why it survives in so many agencies that are otherwise diligent about language access.

What does WCAG say about language?

Two success criteria, both at levels you are obliged to meet:

  • 3.1.1 Language of Page (Level A). The default human language of each page or document must be programmatically determined. In HTML this is the lang attribute; in PDF it is a document-level language entry.
  • 3.1.2 Language of Parts (Level AA). Any passage in a different language from the surrounding content must also be programmatically identified.

Level A and Level AA are both in scope for anything held to WCAG 2.1 AA, which is the standard behind the ADA Title II rule, the HHS Section 504 rule, and Section 508 procurement. Which of those applies to you, and by when, is in the ADA Title II deadline post.

What actually goes wrong

A screen reader chooses its pronunciation rules from the declared language. Give it Spanish text under an English declaration and it applies English phonetics to Spanish spelling.

The result is not a slight accent. “Solicitud de vivienda” read with English rules is not recognisable as those words to a Spanish speaker. A blind resident hears a stream of syllables that means nothing, from a document your agency specifically produced for them. The translation was correct; the delivery destroyed it.

Three variants of the same failure, in rough order of how often we find them:

1. The whole document is untagged or tagged English. Most common. A translator returns a Word file, someone exports it to PDF, and the export inherits the template’s English language setting. The Spanish document declares itself English.

2. A bilingual document declares only one language. Side-by-side English and Spanish, or an English form with Spanish instructions, tagged entirely as English. This is the one 3.1.2 exists for, and side-by-side layouts are common in government forms precisely because they are convenient for sighted readers.

3. The alt text was never translated. The document is correctly marked Spanish, the text reads properly — and every image description is still in English, because alt text lives in metadata and translation workflows routinely skip it. A Spanish-speaking screen reader user gets the document in Spanish and the pictures in English.

There is a fourth that is subtler and worth watching for: proper nouns and untranslated terms. A Spanish document that quotes an English program name — “the Housing Choice Voucher program” — technically needs that passage marked English for correct pronunciation. WCAG allows an exception for proper names and technical terms that have become part of the surrounding language, so this is a judgement call rather than a mechanical rule. In practice, mark the ones that would be mangled.

Does this apply to right-to-left languages too?

It applies more, and the consequences are bigger. Arabic, Hebrew, Farsi and Urdu need the language declared and the reading direction handled, and in PDF the tag tree has to reflect the logical reading order rather than the visual position of text on the page. Get that wrong and the content is read in an order that inverts meaning. We cover that separately in Arabic and RTL PDF accessibility.

How do I check my own documents?

You do not need a specialist to find the biggest problems.

For PDFs, open the document properties in Acrobat and look at the language setting. If a Spanish document says English, you have found failure #1 in ten seconds. Then check whether there is a tag tree at all — no tags means the file is failing far more than the language criteria.

For a scanned document, there is nothing to check. A scan is an image; there is no text and no language. It fails everything, and it needs the text recovered before anything else can be fixed.

For web pages, view source and find the <html lang="..."> attribute, then look for lang on any block in another language.

The real test is a screen reader. Turn on NVDA on Windows or VoiceOver on a Mac and listen to your own translated form for thirty seconds. If it sounds wrong to you, it is unusable to someone who depends on it. That single test convinces internal stakeholders faster than any audit report.

Our PDF accessibility checker will surface the structural issues in a specific file if you would rather start from a report.

Why most vendors leave this gap

Because it sits between two trades.

An accessibility remediation firm tags documents competently and does not read Spanish, so it cannot write Spanish alt text or judge which passages need marking. A translation firm produces excellent Spanish and hands back a Word file, because tagging is not what it does. Each does its half correctly and the client ends up with a document that fails.

Doing it in sequence also means paying twice: translate, then remediate, and the remediation step has to re-derive structure the translation step discarded.

Doing it as one job

The order that works is: structure the source, translate with the structure intact, then tag once in both languages. Alt text is translated as content, not skipped as metadata. Language is set per passage while someone who reads the language is still looking at the file.

That is the work Taika does, and it is the reason we do both trades rather than one. If your agency publishes in more than one language and is now working to a WCAG 2.1 AA deadline, these two projects are actually one project, and running them separately is the expensive way.

Start at document accessibility for the remediation side, or accessibility and compliance services if you are scoping the whole obligation. If your driver is language access rather than accessibility, Title VI language access plans is the companion read.

Have a translated form you are unsure about? Request a quote, tell us the languages you publish in and roughly how many documents, and we will come back with what it takes to make them genuinely usable — not merely translated.

Need this done right?

Taika Translations provides certified translation, interpretation, and accessibility services in 300+ languages.

Get a quote → More resources