PDF Accessibility Services and PDF/UA Remediation
PDF accessibility remediation to PDF/UA-1 and WCAG 2.1 AA for translation agencies, companies and public institutions. Documents become usable with screen readers and keyboards: correct tag structure, a logical reading order, meaningful alternative text and the right language on every passage.
The specialism is multilingual accessible PDFs in European languages, right-to-left scripts such as Arabic, Hindi and CJK. When the InDesign or Word source is available, accessibility is built into the source before translation, so every language version inherits the same structure instead of being repaired file by file. Every delivery is validated with PAC 2026, tested with the NVDA screen reader and documented in a remediation report.
- Standards
- PDF/UA-1 (ISO 14289-1) and WCAG 2.1 AA
- Scripts
- Latin, Cyrillic, Arabic and RTL, Devanagari, CJK
- Sources
- InDesign, Word, PowerPoint, finished or scanned PDFs
- Validation
- PAC 2026, NVDA screen reader, script and link checks
- Delivery
- Accessible PDFs, updated source files, remediation report
- Price
- From €7 per page
- Assessment
- Free, one document, with a firm quote
Who this PDF accessibility service is for
Translation agencies and LSPs
- Accessible PDFs in every target language from one remediated source
- Fits your CAT workflow: Trados Studio, memoQ, IDML and bilingual files
- A remediation report your project manager can forward to the end client
- Confidential handling, with an NDA on request
Companies and public institutions
- Reports, policies, brochures, manuals and forms prepared for accessible publication
- Clear technical targets: PDF/UA-1, WCAG 2.1 AA and EN 301 549
- Direct contact with the specialist working on your files
- Plain-language documentation of what was fixed and what remains
The complete PDF Accessibility Guide covers tags, alt text, WCAG, laws and tools, explained so anyone can understand it.
What PDF accessibility remediation includes
Adding tags is where remediation starts, not where it ends. Every element is checked for what a screen reader announces, in which order and in which language.
Tags and headings
Headings, paragraphs, lists and figures tagged by their role on the page. Heading levels follow the real hierarchy, with no skipped levels.
Reading order
Columns, sidebars and callouts read in the order a sighted reader follows them, defined so it holds after translation.
Alternative text
Written by a person, in context. Machine-generated descriptions are replaced, and images that carry no information are marked as decorative.
Decorative artifacts
Backgrounds, lines, frame fills and repeated page furniture hidden from screen readers, so they don't interrupt the content.
Links and navigation
Descriptive link text, every destination checked, bookmarks built from the headings and a tab order that follows the structure.
Tables
Header cells and scope set, so each value is announced with its row and column.
Forms
Fillable fields with labels, tooltips and a logical tab order.
Language tagging
The document language and every passage in another language, so the screen reader switches pronunciation.
Colour contrast
Text checked against the 4.5:1 ratio. Failing brand colours are flagged with compliant alternatives.
Metadata and PDF/UA flag
Document title shown in the title bar, language and metadata set, PDF/UA identifier applied.
Every point above is built into a four-page sample document. Open it in Acrobat Pro and show the Tags panel; browser PDF viewers do not display tags. PDF/UA, 759 kB.
Accessible multilingual PDFs: fix the source once, before translation
The most expensive way to get accessible PDFs in several languages is to remediate each translated PDF separately. The work is repeated for every language, the results drift between versions, and fixes made in Acrobat disappear the next time the file is exported from InDesign. Remediating the source before translation avoids all three. Background on why translated documents need specialist work: PDF accessibility remediation for multilingual documents.
Fixing each translated PDF
- Structural work repeated in every language
- Tag structure and reading order differ between versions
- Acrobat fixes lost on every re-export
- Wrong machine alt text translated into every language
Fixing the source before translation
- Structure fixed once and inherited by all languages
- Identical structure and reading order in every version
- Only a short final pass per file after the last export
- Unneeded image descriptions removed before the word count
Alt text is translatable content, so CAT tools send it to translators. Replacing inaccurate machine descriptions and marking purely decorative images before translation lowers the word count in every target language, which can offset part of the preparation cost.
What the translation workflow needs to get right
- Approve the remediated source first. A structural change after translation starts has to be made in every language.
- Keep one IDML for the whole project. A new export creates new internal IDs, and files built from different exports stop matching.
- Tell translators whether the layout can grow. If pages can't be added, they balance length against the source.
- Return the translated bilingual file, for example SDLXLIFF, not a regenerated IDML or a review document. Segment counts are checked on arrival, because a partial import reports no error.
- Links and alt text are checked in every language. A translation round-trip can change link destinations and miss alt text on some objects without any warning.
Accessible PDFs in European, RTL, Hindi and CJK languages
Every script fails in its own way, and several of those failures are invisible on the page. Each script family gets its own checks on top of the standard validation. For layout background, see right-to-left languages in InDesign and fonts in multilingual DTP.
European languages
Latin and Cyrillic scripts: German, French, Spanish, Polish, Russian, Ukrainian and more
- Language tag on every passage, so the voice switches correctly
- Font coverage checked for every character
- Text expansion fitted without changing reading order
Right-to-left (RTL)
Arabic, Hebrew
- Mirrored layout with a correct reading order
- Embedded English tagged as English
- Arabic text extracted and verified character by character
Devanagari
Hindi
- Extracted text checked for doubled or broken vowel signs
- Text composer verified per paragraph style
CJK
Chinese (Simplified and Traditional), Japanese, Korean
- Line-breaking rules set per language
- Fonts verified for full character coverage
- Correct language tag for each variant
Some builds of widely used Arabic fonts display perfectly but store the letters in a way that breaks copying, search and screen readers. A file in that state can pass PDF/UA in full. Arabic fonts are screened before layout, and every Arabic PDF is checked after export.
What PDF accessibility checkers don't catch
PAC and the Acrobat checker test what software can measure: whether tags exist, whether alt text exists, whether a language is set. They can't tell whether any of it is right. Each of these passes automated validation:
The document is read in the wrong language
Some InDesign builds write a fixed language onto the document on export, whatever its real language. Everything is pronounced with the wrong rules.
Arabic text that can't be read
The page looks perfect, but the font stores letters so that copying, search and screen readers get the wrong characters.
Links that go nowhere
After a translation round-trip, a link can lose its destination while staying tagged, underlined and clickable.
Text outside the reading order
A frame pasted or replaced late in layout can drop out of the structure. Its text is never read aloud.
Alt text that exists but is wrong
Machine-generated descriptions satisfy the checker, mislead the listener and get translated into every language.
Heading levels that are valid but wrong
Levels assigned by style name instead of role produce an outline that validates but doesn't match the page.
Automated validation with PAC 2026 against PDF/UA-1, testing with the NVDA screen reader including language switching, text extraction checks for complex scripts, and every link checked against its destination. A checker pass is required, but never treated as proof.
Not sure what shape your file is in?
Send the PDF and, if you have it, the source. You get the main risks, a quote and a timeline back in writing, at no cost.
How a PDF accessibility project runs
Single-language projects follow the steps marked All projects. Multilingual projects add the translation and language-version steps.
Free document assessment
All projectsThe PDF and any source files are reviewed. You get the main risks (for example machine alt text, no defined reading order, fonts missing characters, failing contrast), a quote, and a timeline per language and in total.
Source preparation
Source filesStructure is fixed in InDesign or Word: heading levels mapped, reading order defined, decorative objects artifacted, alt text written and fonts chosen for every target script. Linked frames are separated so text expansion stays in its own box.
Review and approval
All projectsYou and your client review the accessible PDF in the source language. On multilingual projects, approval comes before translation starts.
Translation in your CAT tool
MultilingualBilingual files can be prepared from the approved source. On return, segment counts, links and alt text are checked before layout.
Layout of each language
MultilingualText expansion, RTL mirroring and CJK line-breaking handled in InDesign, with review rounds per language.
Final pass and validation
All projectsCorrections that only work after the last export (document language, tab order, PDF/UA identifier, bookmarks), then PAC 2026, NVDA and script checks.
Delivery and report
All projectsAccessible PDFs, validation results, updated source files and the remediation report.
What you receive
- Accessible PDF for each language
- Validation results from PAC 2026
- Remediation report with findings, decisions and notes
- Updated source files when work was done at source, so future revisions don't start from zero
- Font notes: where a specific font build is required, it's named, and supplied where the licence allows
- Summary and standard applied
- Issues found and how each was resolved
- Validation results by checkpoint
- Decisions needed from you or your client
- Language-specific notes
- Remaining warnings, explained
Remaining warnings are explained, so your client's accessibility team doesn't report them as defects.
Pricing and turnaround
Remediation is priced per page, banded by the actual complexity of each page rather than a single rate across the whole document. A 40-page report with eight table-heavy pages is quoted as 32 standard pages plus eight complex pages, not at the higher rate throughout. More on how DTP is priced per page.
| Service | What it covers | Rate |
|---|---|---|
| Standard page | Text-led pages with a linear reading order, headings, lists, links and simple images | from €7 per page |
| Complex page | RTL, Devanagari and CJK scripts, tables, forms, footnotes and meaningful diagrams | from €11 per page |
| Multilingual DTP | Layout of each translated language version in InDesign, two revision rounds included | from €4 per page |
| Source preparation | Structure, paragraph styles, reading order and fonts fixed in InDesign or Word, once for the whole project | €69 per hour |
| Scanned PDFs and OCR | Conversion to real text and table recreation before remediation starts | €69 per hour |
All rates are net. The figures marked "from" are entry rates: which share of your document falls into which band only shows once the file is open, which is what the free assessment is for. Rush delivery is agreed in advance and quoted separately.
| Factor | Effect on the quote |
|---|---|
| Page count | Remediation and layout are priced per page. |
| Script and content | Standard rate for Latin and Cyrillic. Complex rate for RTL, Devanagari, CJK, tables and forms. |
| Source file condition | Source preparation is €69 per hour, with the hours quoted after the assessment. Problems such as linked frames or machine alt text only show inside the file. |
| Source files or PDF only | With InDesign or Word, fixes survive re-export and carry into every language. With a PDF only, fixes are made per file. |
| Number of languages | Source preparation happens once. Layout and the final pass are per language. |
| Deadline | Turnaround is quoted per language and for the whole project. Rush delivery is agreed in advance. |
Firm quotes are given on the final source file; drafts get an indicative quote. If a translation round-trip damages the file structure, the repair is quoted by the hour and approved by you before work starts.
PDF/UA, WCAG, EN 301 549 and the EAA: what applies
Standards describe how an accessible PDF is built. Laws decide who has to publish accessible documents. Remediation delivers the first; whether that meets your obligations depends on the second.
| Standard or law | What it means for your PDF |
|---|---|
| PDF/UA-1 (ISO 14289-1) | The technical standard for accessible PDF. Target for every file, validated with PAC 2026 against the Matterhorn Protocol and checked manually. |
| WCAG 2.1 AA | Criteria such as text alternatives, contrast and link purpose, applied to documents. Target level for every file. |
| WCAG 2.2 AA | Adds criteria mostly aimed at interactive content. If your requirements name WCAG 2.2, the extra criteria are assessed before quoting. |
| EN 301 549 | The European ICT accessibility standard, including documents, used in public procurement. Version 3.2.1 (WCAG 2.1 AA) is currently cited. Version 4.1.1, published in September 2026, is based on WCAG 2.2 and takes over once it is cited in the EU Official Journal. |
| European Accessibility Act and BFSG | Since 28 June 2025, accessibility duties for specific products and services, such as e-commerce, banking, e-books and passenger transport. The law names no PDF standard; PDF/UA and WCAG are the usual technical route. |
| Web Accessibility Directive and BITV 2.0 | Websites, apps and documents published by public bodies. BITV 2.0 applies to German federal bodies; German states and municipalities follow their own state law. Files are remediated to the requirement your authority sets. |
| Section 508 (US) | US federal requirements based on WCAG 2.0 AA, which a WCAG 2.1 AA target covers. |
Each file's technical conformance is validated and documented. Whether a document meets your legal obligations depends on who publishes it, where and for what purpose, which is a legal assessment rather than remediation work. Include any specific requirements in your brief and the scope is checked before quoting.
PDF accessibility FAQ
Can you make a PDF accessible without the InDesign or Word source?
Yes. Finished PDFs are remediated directly. The limitation is that the work lives only in that PDF: if the file is exported again or translated, the fixes have to be repeated. With the source, structural fixes are made once and survive.
What does it cost to make a PDF accessible?
From €7 per standard page and from €11 per complex page, net. Pages are banded individually within a document rather than charged at one rate throughout, so a mostly text-led report with a few table-heavy pages is quoted accordingly. Source preparation and scanned-PDF conversion are €69 per hour, with the hours quoted after the free assessment, because the effort only shows once the file is open. Full rates are in pricing and turnaround.
Our PDF passes the accessibility checker. Is it accessible?
Not necessarily. Checkers confirm that tags, alt text and a language exist. They can't judge whether the alt text is accurate, the reading order makes sense or the language is the right one. See what checkers don't catch.
Should accessibility work happen before or after translation?
Structural work belongs before translation, on the source: headings, reading order, artifacts and alt text. After layout, each language gets a short final pass and full validation. Doing structural work after translation means doing it once per language.
Does alt text need to be translated?
Yes. Alt text is read aloud, so it has to be in the document's language. CAT tools extract most of it, but some filters miss alt text on certain objects, so every language version is checked for untranslated descriptions. Include alt text in the translation word count.
Which files should translators return?
The translated bilingual file from your CAT tool, for example SDLXLIFF, with the segmentation that was issued. A target file regenerated elsewhere, or a review document imported back into the project, can drop segments without an error message.
Which file formats and CAT tools do you work with?
InDesign (INDD and IDML), Word and PowerPoint, with Trados Studio and memoQ on the translation side. Known IDML filter problems with hyperlinks are repaired in the file before translation. See INDD vs IDML for translation.
What if the source changes after translation has started?
Text corrections are simple. Structural changes, such as new frames, new pages or a different heading hierarchy, have to be made in every language and validated again. That's why the source is approved before translators start.
Do decorative stock photos need alt text?
Only if they carry information the text doesn't. Each image is assessed: if removing it loses nothing, it's marked as decorative, so screen reader users aren't interrupted and the translation stays shorter. If your client prefers descriptions, they're added in every language.
What happens when brand colours fail contrast?
Failing combinations are flagged with their ratio and a compliant alternative. Brand colours are your client's decision, so the change is agreed before it's applied.
Do you also handle forms, tables, Word files and scanned PDFs?
Yes. Forms get labels, tooltips and a logical tab order; tables get header cells and scope. Word and PowerPoint files can be fixed at source. Scanned PDFs are first converted to real text with OCR and recreated tables, then made accessible.
What should we send for a quote?
The PDF, the packaged source files if available (InDesign package with links and fonts, or the Word file), the target languages, the standard your client requires, the deadline and how translation will be handled. The Project Brief Generator helps you put this together.
How long does a project take?
It depends on page count, scripts, source condition and review time. Timelines are quoted per language and for the whole project, with your review rounds included, so the schedule can be checked against your client's deadline before work starts.
Do you guarantee legal compliance?
No. Technical conformance to PDF/UA-1 and WCAG 2.1 AA is validated and documented for each file. Legal compliance depends on who publishes the document, where and why, and requires a legal assessment.
Can you work under an NDA?
Yes. An NDA can be signed before any files are shared.
What if the end client's accessibility team raises questions after delivery?
The report already explains the remaining warnings and why they aren't defects, which answers most questions. Issues within the agreed scope are corrected.
Who does the work
Onur Ilter, Berlin. Multilingual DTP and PDF accessibility specialist, working in translation and desktop publishing since 2004. Associate Member of the ITI (Institute of Translation and Interpreting). More about the background
Request a free document assessment
Send the PDF and, if available, the source files. You'll receive the scope, the main risks, a quote and a timeline per language and in total, based on the actual document.
Get in touch → Prefer to prepare a brief first? Use the Project Brief Generator