The European Accessibility Act and Translated Documents: What Businesses Must Get Right

A German machinery supplier asked us something last spring that we have heard in different forms ever since. Their operating manuals were accessible in German: tagged, structured, screen-reader tested, signed off by a consultant they had paid a lot of money. Then they translated those manuals into six languages and shipped the results to distributors across the EU. Were the translations compliant?

Nobody had checked. That is the pattern. European Accessibility Act translation work falls into a gap: accessibility gets solved in the source language, translation happens later, in a different tool, run by different people, and the handoff between them loses things nobody is watching for. This is about what gets lost, and how to stop losing it.

What the EAA actually covers

The European Accessibility Act, Directive (EU) 2019/882, has applied since 28 June 2025. It sets accessibility requirements for a defined list of products and services sold to EU consumers: e-commerce, consumer banking, e-books, transport services, telecoms, computers and operating systems, ticketing and check-in machines, and several others.

Two things about that scope matter to anyone producing documents.

First, the obligation reaches the documentation attached to a covered product or service, not just its interface. If you sell a covered service, the support materials, terms, and instructions that come with it sit inside scope. A PDF explaining how to use an accessible banking app is part of the service.

Second, the technical yardstick is EN 301 549, which pulls in WCAG 2.1 Level AA. For documents that means tagged structure, real headings rather than bold text pretending to be headings, alternative text on images that carry meaning, table header markup, a sensible reading order, and a declared document language. PDF/UA (ISO 14289) is the usual reference for tagged PDF, though the EAA does not name it directly.

The limits are worth knowing too, because plenty of businesses assume they are covered when they are not. Microenterprises providing services, meaning under ten employees and under €2 million turnover, are exempt from the service obligations. Some existing arrangements have a transition window running to 28 June 2030. And because the EAA is a directive rather than a regulation, enforcement lives in national implementing law and varies between member states in how it is policed and what it costs you when it goes wrong.

Why European Accessibility Act translation is a document problem

Most compliance advice treats accessibility as a web problem. Websites get audited, remediated, monitored. Documents get exported and emailed.

We watch the consequence play out repeatedly. A company runs a serious accessibility project, fixes its source PDFs and DOCX files, then hands those files to a translation vendor with a purchase order and a deadline. What comes back is a translated document. Whether it is still an accessible document is nobody's job.

The vendor did not do anything wrong. Standard translation workflows are built to move text, not markup. A CAT tool extracts translatable segments and writes them back. Some tools handle tags well, some flatten them, and almost none treat accessibility metadata as content requiring attention. Alternative text illustrates this well: in a DOCX it lives in a drawing property, not in a paragraph. Depending on the filter, it either comes through as a segment or does not come through at all. When it does not, the translated manual still carries German alt text on every diagram, read aloud by a French screen reader voice.

This is not hypothetical. We reviewed a set of translated technical manuals for a customer last year and found alt text untranslated in all five target languages. The visible body text was clean. The layout was clean. A sighted reviewer would have signed off on every one of them, because this failure is invisible unless you go looking.

The rule we now give people is short: accessibility is a property of the file, and translation produces a new file. The new file needs its own check.

The language attribute nobody remembers

If you fix one thing after reading this, fix this one.

Screen readers pick pronunciation rules from the document's declared language. A PDF carries a /Lang entry. A DOCX carries language properties on runs and on the document defaults. When those still say de-DE and the text is Polish, a screen reader reads Polish words through German phonetics. The output is not slightly degraded. It is unintelligible.

WCAG 2.1 addresses this in two places: 3.1.1 Language of Page at Level A, and 3.1.2 Language of Parts at Level AA. Both sit inside EN 301 549, which puts both inside EAA scope for covered documents.

Translation tools inherit this value rather than setting it. When a CAT tool writes translated segments back into a DOCX, it usually preserves the run properties from the source, language flag included. Word then applies its own proofing-language logic on top, which is why you sometimes open a translated file and find red squiggles under every single word. That underline is the visible symptom of the problem an assistive technology user hits silently.

Language of Parts deserves separate attention in translated material, because translated documents mix languages more than source documents do. Product names, legal citations, standard references, company addresses, and occasionally whole quoted passages stay in the source language. Each of those spans needs its own language marking, or the screen reader will mispronounce them in the opposite direction.

Checking the document-level value takes seconds. In Word, select all and read the language indicator in the status bar. In a PDF, open document properties and check the language field. Fixing it takes seconds too. Almost nobody does it, because it is on nobody's checklist.

What survives a round trip and what does not

Structure usually survives. Heading levels, list markup, and table structure live in the file format itself, and any competent DOCX or PPTX filter reproduces them. If a source document uses real Heading 1 and Heading 2 styles, the translation normally keeps them.

The things that break are the ones stored outside the text flow.

Alt text, as above. Table header rows, which in DOCX are a row property rather than text: these survive translation itself, then get destroyed later when someone adjusts a table by hand because the translated headers no longer fit the column widths. Bookmarks and internal cross-references, which can end up pointing at heading text that has changed. Reading order in PPTX, where the shape order on a slide determines the sequence a screen reader announces, and where a well-meant layout fix after translation reorders shapes without anyone noticing what moved.

Spreadsheets have their own version of this. XLSX workbook translation preserves cell content reliably, but sheet tab names, named ranges, and data validation lists often stay in the source language while the visible cells change. A screen reader user navigating a translated price list hears translated products inside sheets still called "Preisliste 2026". Merged cells are worse: they were already an accessibility problem in the source, and translated text that no longer fits tends to produce more of them.

PDF is the harsh case. A tagged PDF that goes through a translation workflow and returns as a fresh export from a DTP application carries whatever tagging that export produced, which is frequently none. If the source PDF was remediated by hand, none of that remediation travels. We have written before about what to do when a document's layout breaks after translation; the accessibility version is worse, because layout damage announces itself and tag damage does not.

The practical consequence: if a document has to stay accessible, translate the editable source, not the PDF. Translate the DOCX or the InDesign file, re-export with tagging enabled, then re-check. Translating a finished PDF and expecting an accessible PDF back is a workflow that cannot succeed. Our guide on how to translate a PDF and keep the original layout covers why PDF makes a poor source format in general.

Text expansion is an accessibility issue too

German typically runs 20 to 35 percent longer than English. Finnish and Polish expand as well. Arabic and Chinese usually contract.

Designers know this. What gets missed is that the standard fixes for expansion damage accessibility. Shrinking the font below the source size runs into WCAG 1.4.4, which requires text to stay usable at 200 percent zoom without loss of content. Tightening line spacing collides with 1.4.12 Text Spacing. Converting overflowing text into an image to hold the layout removes it from the accessibility tree entirely, which is 1.4.5 Images of Text.

The clearest pattern is in slide decks. A deck gets translated into German, three bullets overflow their placeholder, and someone resolves it by dropping the font from 18pt to 12pt and replacing one dense bullet with a screenshot of the original table. The deck looks fine in the review meeting. It is now less accessible than the English original, and the person who made both changes was trying to help.

The alternative is planning for expansion in the source: leave roughly 30 percent slack in text containers, avoid fixed-height boxes for translatable content, and accept that a translated deck may need an extra slide rather than smaller type. That decision belongs to whoever owns the source template, which means it has to happen before translation starts rather than during review.

Building the check into the workflow

The reason accessibility gets lost here is organisational, not technical. Translation is bought as a text service and delivered against a linguistic quality standard. Accessibility is bought separately, if at all, and audited against a different standard by different people. Nobody owns the seam between them.

Three changes fix most of it, and none of them need new tooling.

Put accessibility in the translation brief. Name the target standard, state explicitly that alt text and language attributes are in scope, and define the deliverable as an accessible file rather than as translated text. Vendors respond to written requirements. They do not respond to assumptions about what was obviously implied.

Give the translator the alt text as translatable content. If your tooling does not extract it, pull it into a separate list and send it alongside the files, then paste it back on delivery. Nimdzi has written about how the EAA is pushing accessibility work into language service scopes, and this is the least interesting part of that shift. It is also the part that gets skipped.

Re-run the accessibility check on the target file. Not the source. The target, in every language. This is where budgets crack, because the cost multiplies by language count, but a checker run costs almost nothing next to the remediation it prevents. Assign it to a named person. Left unassigned, it does not happen.

If an AI translation step sits in front of your CAT tool, the same rule applies to it. SnapIntel, our own product, accepts DOCX, XLSX, and PPTX files, prepares a glossary and a translation prompt for the specific document, runs the translation, and returns the translated file along with a QA report and a neutral source/target XLSX you can import into any CAT tool or translation memory. Formatting for supported containers comes back intact. What it does not do, and what no translation tool we are aware of does, is accessibility remediation. If the source document was untagged or missing alt text, the translated one will be too. That part stays with you.

The ten-minute check before you ship

Take one translated file per target language, not all of them, and run through this.

Open the document properties and confirm the declared language matches the target. In Word, select all and confirm the proofing language while you are there.

Open the alt text on three images. If those three are still in the source language, the rest of the set is too.

Confirm headings are real styles rather than manual formatting, and that heading levels match the source. A missing H2 usually means someone rebuilt a section by hand.

For tables, confirm the header row is still marked as a header row and still repeats across page breaks.

For PPTX, open the selection pane on two slides and read the shape order aloud. That is the order a screen reader will use.

For PDF deliverables, run an accessibility checker. Acrobat has one built in and PAC is free; either will catch missing tags in under a minute.

If a language fails any of these, the rest of that language will fail the same way, because the cause is the workflow rather than the file. Fix the workflow once and the other files stop failing.

The German supplier from the opening, for the record, failed on language attributes in all six languages and on alt text in four. Their consultant had audited the German source and nobody thought to look downstream of it. The repair took about a day. The useful outcome was not the repair. It was one added line in the translation purchase order requiring the target language attribute to be set correctly on delivery. That line has held for a year now, across three vendors.