Accessibility often doesn’t survive translation. Many translation workflows extract the text from a Portable Document Format (PDF) file, translate it, and rebuild the file, which strips the tags (the hidden structure a screen reader follows), reading order, alt text, and language settings that made the original accessible. The reliable approach is to translate the accessible source file and then run PDF accessibility testing on every language version to confirm the tags, reading order, and language settings came through.
For a student who reads course material in Spanish with a screen reader, an untagged translated handout isn’t a slightly weaker version of the English one. It’s an unreadable one, even though the classmate next to them opened the English file without a second thought. The translation was paid for; the access wasn’t delivered.
Most translation guides treat accessibility as someone else’s job after the words are done, and most PDF accessibility guides never mention translation at all. The failures happen in the handoff between the two, which is exactly where neither kind of guide is looking.
The translation step that breaks PDF accessibility tags
Tags break because the PDF is usually treated as a container for text rather than as a structured document. A translator or translation tool pulls the text out and returns translated text, and a desktop publisher places it back into a layout. The tags, the reading order, and the alt text were never part of what got translated, so they don’t come back. If the rebuilt file is then auto-tagged to “fix” it, the result usually passes a basic checker while reading in the wrong order.
Text length makes it worse. Translated text often runs longer than the English original, so paragraphs reflow, captions shift, and tables get split across pages. Every one of those layout changes is a chance for the reading order to drift away from the visual order.
Common translated-PDF failures and their fixes
| What breaks | Why it happens in translation | What works |
| The tag tree disappears | Text is extracted and the file is rebuilt from scratch | Translate the accessible source file (Word, InDesign, or PowerPoint), not the exported PDF |
| Reading order drifts | Longer translated text reflows the layout | Re-check reading order in each language version after final layout |
| Alt text stays in English | Alt text isn’t visible on the page, so it’s left out of the translation package | Export alt text with the rest of the content and translate it like body copy |
| Document language still says English | The language setting is copied from the original file | Set the document language to the target language before export |
| Mixed-language passages aren’t marked | Quoted terms or citations stay in the original language without a language tag | Tag passages in another language so a screen reader switches pronunciation |
| Text looks right but reads as nothing | A new font for the target script lacks Unicode mapping | Test by copying text into a plain-text editor; if it pastes as symbols, the font needs fixing |
| Form tooltips, bookmarks, and the title stay in English | They sit in file properties, not on the visible page | Add tooltips, bookmarks, and the document title to the translation checklist |
WCAG language requirements for translated documents
The Web Content Accessibility Guidelines (WCAG) set two language requirements. Success criterion 3.1.1 (Language of Page) requires the document’s default language to be declared, and 3.1.2 (Language of Parts) requires passages in a different language to be marked. Both fall within WCAG 2.1 Level AA. This is what tells a screen reader which pronunciation rules to use. A Spanish PDF still declared as English is read with English pronunciation, word by word, which is close to unintelligible.
A translated-PDF failure in practice
It usually looks perfect. One of the most deceptive failures in translated files is a font problem, not a tagging problem. The translated text renders correctly on screen, the tag tree is intact, and the checker reports no errors. But the embedded font lacks Unicode mapping, the link between each letter shape and the character it represents, so a screen reader announces blank space or nonsense. The PDF/Universal Accessibility standard requires text to map to Unicode for exactly this reason. The fastest check anyone can run is to copy a paragraph and paste it into a plain-text editor.
Translate the source file, not the PDF
Work from the source file whenever it exists. Word, InDesign, and PowerPoint files carry real headings, alt text, and table structure that translation tools can preserve, and they export to a tagged PDF in each language. Translating from the PDF means rebuilding that structure by hand for every language, every time the document is updated.
The same PDF accessibility remediation steps apply to every language, in this order:
- Remediate the source file in the original language first, so every translation inherits a correct structure.
- Send the translation team the source file plus alt text, form tooltips, bookmarks, and the document title.
- Set the target language in the file before exporting, and tag any passages left in another language.
- Export a tagged PDF, and then verify the reading order and read the file with a screen reader set to that language.
Remediation steps when only the PDF exists
Start with PDF remediation in the original language before anything is translated. A common, expensive mistake is translating an inaccessible PDF and then remediating each language separately, which multiplies the same structural fix by the number of languages. Fixing the original once and then converting it back into an editable source file for translation avoids repeating the same fix in every language. Then budget for a screen-reader check in each target language, not only in English.
ADA Title II coverage for translated documents
Title II of the Americans with Disabilities Act (ADA) applies to every language version of a document a public institution publishes online, apart from a few narrow exceptions, such as archived content. The Department of Justice (DOJ) rule under Title II adopts WCAG 2.1 Level AA, so a translated financial aid guide is held to the same standard as the English one. On April 20, 2026, the DOJ published an interim final rule setting two compliance dates. Public entities with a total population of 50,000 or more, a group that includes most public colleges and universities, must comply by April 26, 2027. Smaller entities and special district governments have until April 26, 2028. The same logic applies to translated subtitles on lecture recordings, which need the same accuracy and review as the original captions.
Five checks before the next PDF goes to translation
- Confirm the source file exists and is itself accessible before it goes out for translation.
- Put alt text, tooltips, bookmarks, and the document title on the translation brief, not just the visible text.
- Ask the translation provider how they preserve structure and whether they deliver a tagged file or translated text only.
- Check each returned file for the correct document language, and paste a paragraph into a plain-text editor to test the font.
- Read the final file with a screen reader set to the target language before publishing it to the learning management system or website.
Translation and accessibility are usually bought separately, reviewed by different people, and signed off on different days. Treating them as one deliverable, checked once in each language, is what keeps the second version from quietly undoing the first. The checks are the same whether the work stays with an in-house team or goes to outside document accessibility services.
If your team is translating documents faster than it can check them, ContentA11Y can deliver each language version as an accessible file, manually verified and screen-reader reviewed rather than auto-tagged. We can review a sample of your translated documents at no cost and show you where the structure broke before the next batch goes out.