How to Make a PDF Accessible: A Practical Guide for Manuals, Catalogues and Reports in Several Languages
To make a PDF accessible, you give it a hidden structure that assistive technology can read: tags for every heading, paragraph, list, table and image, a logical reading order, alternative text, the correct language and embedded, readable fonts, then you test it against PDF/UA (ISO 14289-1) and WCAG. DEMA Solutions builds this into multilingual documentation, so every language version is accessible, not only the original.
Who this guide is for
This guide is for the people who own documents rather than websites: technical documentation managers responsible for manuals, marketing managers who publish catalogues and brochures, and compliance or quality managers who have been asked whether the company’s PDFs meet accessibility requirements. Most of them publish in several languages, and most have discovered that ticking an export option does not produce a compliant file.
Their questions are practical. Which standard applies? Can it be fixed in Word or InDesign? What happens to accessibility when a manual is translated into eight languages? And what should a request to a supplier say?
What an accessible PDF is, and why "Save as PDF" is not enough
A PDF has two layers. The visible layer is what a sighted reader sees: text, columns, tables and pictures. Underneath, an accessible PDF has a second layer, the tag tree, which tells assistive technology what each piece of content is and in what order to read it. A screen reader or a braille display does not look at the page. It reads the tags.
If the tags are missing, the document is a picture of text to that software. If they are wrong, the result can be worse: a two-column page read straight across both columns, a table announced as a stream of unrelated numbers, a safety warning read after the step it refers to. A PDF can look perfect and still be unusable for someone who cannot see it.
That is why “Save as PDF” is rarely enough. Office and layout programs can export tagged PDFs, but the export only converts what the source contains. If headings were made by enlarging the font, if images have no alternative text, if a table was drawn with tabs and lines, the PDF inherits every one of those problems. Learning how to make documents accessible is mostly learning how to build the source so the export has something correct to convert.
PDF accessibility standards: PDF/UA, WCAG and EN 301 549
Three references come up in every conversation about PDF accessibility standards.
PDF/UA is the international standard for accessible PDF files, ISO 14289. Part 1, ISO 14289-1, is the version most organisations work to today; Part 2 was published in 2024 for files based on PDF 2.0. PDF/UA specifies the file: all meaningful content tagged with the right semantic meaning, decorative content marked as artifacts, fonts embedded and mapped to Unicode, a document title and declared language, and no security settings that block assistive technology. PDF/UA compliance means the file meets these requirements.
WCAG, the W3C’s Web Content Accessibility Guidelines, describes accessible content rather than a file format. Version 2.1 is the level most European rules refer to; version 2.2, published in 2023, adds criteria that mainly concern interactive web content. WCAG asks questions PDF/UA does not: is colour contrast sufficient, is information conveyed by colour alone, does link text make sense?
EN 301 549 is the European standard for the accessibility of ICT products and services. Its clause on non-web documents applies WCAG success criteria to files such as PDFs, which is how WCAG reaches documents in European public procurement and in EU accessibility law. A revision aligned with the European Accessibility Act is in preparation.
So the honest answer to “PDF/UA vs WCAG” is that you need both. PDF/UA checks that the file is built to be read by assistive technology; WCAG, through EN 301 549, checks that the content is perceivable, operable, understandable and robust. A file can pass a PDF/UA check and fail WCAG on contrast, and a well-written document fails both if it is not tagged.
Who has to publish accessible PDFs
Public sector bodies in the EU have had to make documents on their websites accessible for several years under the Web Accessibility Directive. Since 28 June 2025, the European Accessibility Act, Directive (EU) 2019/882, has applied to a defined list of consumer products and services, including computers and smartphones, self-service terminals, e-readers, banking services, e-commerce, e-books, passenger transport services and electronic communications. For products in scope, the information on use, including instructions and safety information, must be accessible. National laws such as Germany’s BFSG, Italy’s Legislative Decree 82/2022 and Spain’s Law 11/2023 transpose the Act, with exemptions such as the one for microenterprises providing services.
Purely industrial equipment sold business to business is largely outside the Act. Many manufacturers are asked for accessible documents anyway: by public buyers who apply EN 301 549 in tenders, by group policies, by distributors in consumer channels, or because the same manual serves professional and private users. Whether a particular document is legally in scope is a question for your legal or compliance team. The technical work is the same either way. For a first view of whether the law reaches your products, our overview of which documents the European Accessibility Act covers walks through scope, exemptions and deadlines.
What makes a PDF accessible: the elements that matter
It is more useful to understand what each requirement does for the reader than to tick a list, because that tells you where your documents are likely to fail.
Tags and headings. Every piece of meaningful content needs a tag describing its role: heading, paragraph, list, table, figure, link. Headings must form a logical hierarchy without skipped levels. In a 200-page manual, headings are how a screen reader user navigates.
Reading order. The tag order must follow the logical order of the content, not the order in which objects were placed on the page. Multi-column layouts, sidebars, warning boxes and captions are where it breaks most often, and in technical documentation a warning read after the step it qualifies is not a cosmetic problem.
Artifacts. Running headers, footers, page numbers and decorative graphics must be marked as artifacts so they are ignored, otherwise the reader hears the title and page number on every page.
Alternative text. Every informative image, diagram and chart needs a short text alternative that conveys its meaning in context. A photo of a control panel needs a description of what the reader should see or do, not “image of panel”. Complex diagrams may need a longer description in the body text.
Tables. Header cells must be marked as headers with their scope, so each value is announced with its row and column. Spare parts lists and technical data sheets are where screen reader users get lost first. Tables used only for layout should not be tagged as tables.
Language. The document must declare its main language, and passages in another language need their own language tag. Without it, a screen reader reads German text with Italian pronunciation. In multilingual documents, this is one of the most frequently forgotten settings.
Fonts, links and metadata. Fonts must be embedded and every character mapped to Unicode so text can be read aloud and searched. Links need meaningful text, long documents need bookmarks that mirror the headings, and the file needs a real title shown instead of the file name.
Forms and colour. Form fields need accessible names, instructions and a logical tab order; a service request form that only works with a mouse is not accessible. Text needs sufficient contrast, and “replace the parts marked in red” fails many readers, with or without assistive technology.
How to make a PDF accessible from the source: Word, InDesign and FrameMaker
The cheapest accessible PDF is the one built correctly before export. Almost every requirement above can be prepared in the authoring tool, so the remaining work is checking and finishing rather than rebuilding.
In Word, that means real heading styles, built-in lists and tables with a defined header row, alternative text on every image, a title and language in the file properties, and the export option that creates a tagged PDF. Documents prepared this way often need only limited correction, although text boxes and floating images still cause problems.
In InDesign, which produces most catalogues and many manuals, the key steps are mapping paragraph styles to export tags, defining the reading order of the layout, adding alternative text through the object export options, marking decorative objects as artifacts, and setting language and title before export. Layouts with many independent text frames need the most attention. Several of the layout features involved are covered in our article on recent design software updates for multilingual desktop publishing.
FrameMaker and other structured authoring environments have an advantage: structured content already describes what each element is, so the mapping to PDF tags can be defined once and reused across every manual.
The principle is the same in all three: accessibility is designed into templates, styles and production rules, not added to individual files. A template that maps styles to tags correctly makes every future document cheaper to finish; one that does not makes every future document a remediation job.
Remediating a finished PDF
Sometimes there is no usable source: the layout files are lost, the document came from a third party, or it is an old file that still has to be published. Then the structure is added to the PDF itself. Tags are created or corrected, reading order rebuilt, artifacts marked, alternative text written, tables restructured, and metadata, language and security settings fixed.
This is skilled manual work. Automatic tagging gives a starting point, but it guesses structure from the visual layout and regularly gets headings, tables and reading order wrong. Remediation also has a structural weakness: it is done on a final output, so when the document is updated, the corrections are lost unless they are carried back into the source. For documents that change regularly, such as manuals, price lists and catalogues, fixing the source is almost always the better investment. For static archive documents, remediating the PDF directly is often sensible.
How to check a PDF: automated tests and manual review
Checking has two halves, and both are needed. Automated checkers, including free PDF/UA validators, test what software can measure: tagged content, embedded fonts, title and language, table headers, the presence of alternative text. They are fast, objective and catch many errors.
What they cannot judge is meaning. A checker confirms that a figure has alternative text, not whether “figure 1” is a useful description; that tags exist, not whether the reading order makes sense. The Matterhorn Protocol, the PDF Association’s catalogue of PDF/UA failure conditions, separates checks software can perform from those needing human judgement, and a substantial part falls into the second group. A practical PDF accessibility checklist for the manual review covers at least these points:
- Read the document with a screen reader, or review the tag tree and reading order, from start to finish.
- Check that headings and bookmarks match the real structure.
- Listen to the key tables and confirm each value is announced with its headers.
- Read the alternative text of every informative image in context.
- Confirm the document language and every language change.
- Test links, form fields and tab order with the keyboard only.
- Check colour contrast and information conveyed by colour.
When you receive accessible PDFs from a supplier, ask for the validation evidence: the automated report and a record of the manual checks. A file without it is a promise rather than a result.
Multilingual documents: every language version must be accessible
Accessibility does not travel automatically through translation. If the English manual is accessible and eight translations are produced by replacing the text and exporting again, each new PDF has to be checked, and several things typically break.
The document language is the most common: translated files often keep the source setting, so a screen reader reads Polish text with English pronunciation. Text expansion changes the layout, frames overflow, text moves into new boxes, and a reading order that was correct in the source no longer is. Alternative text is easy to forget because it is hidden in object properties, so it stays in the source language unless the translation process extracts it. Bookmarks, metadata titles and form field names have the same problem, and fonts that cover the source language may lack characters for others.
The fix is to treat accessibility as part of the multilingual production chain. Alternative text, titles, bookmarks and form labels are exported for translation with the visible text. Terminology in alternative text follows the same approved glossary as the manual, which is why keeping technical terminology consistent across translators and suppliers matters here too. Layout is adapted in the source files by people who understand both the language and the tagging, the work of multilingual desktop publishing. And the checks are repeated on the final file in every target language.
Preparation before translation helps too, since clean, well-structured source files are cheaper to translate, lay out and make accessible; how DTP file preparation works explains what it involves. For product manuals, accessibility sits alongside the legal language requirements set out in our guide to user manual translation, and the provisions on digital instructions in the Machinery Regulation make well-structured digital formats more important for machinery manufacturers from 2027.
What drives the cost of accessible PDFs
There is no meaningful price per page, because effort depends on the document rather than its length. Four factors decide most of it.
The starting point. A well-built source that needs tag mapping and checks costs a fraction of a scanned or flattened PDF that must be rebuilt. Source quality is the largest single driver.
Layout complexity. Multi-column catalogues, overlapping graphics, callout boxes and dense tables each add work, mostly in reading order and table structure.
Images and forms. A report with five charts and a parts catalogue with four hundred illustrations are different projects, because good alternative text for technical images needs subject knowledge. Fillable forms need field-by-field work.
Languages and updates. Each language version needs its own finishing and checks. As an illustration, a manual in six languages updated twice a year is not one remediation project but twelve a year, unless accessibility lives in the source files and the production process.
Doing it in-house or with a provider
Many companies can handle simple documents themselves. If your team produces reports in Word, training authors to use styles, alternative text and the right export settings, plus an automated check before publication, solves much of the problem at low cost.
The calculation changes with volume, complexity and languages. Complex layouts, technical illustrations and forms need specialist knowledge of tagging and assistive technology. A provider makes most sense when documents are complex, multilingual or frequently updated, or when you need documented evidence for a customer or public buyer. A separate article in this series looks at those trade-offs in more detail.
How to brief a provider
A good brief avoids disputes about what “accessible” meant. State the target standard (for example PDF/UA-1 and WCAG 2.1 level AA, or the requirements of a specific tender), the documents and formats, and whether editable source files are available. List the languages and update frequency, and say whether the accessible structure must be built into the source templates or only the delivered PDFs. Decide who writes or approves alternative text for technical images, because that needs product knowledge, and what validation evidence you expect.
In return, ask how the provider checks reading order and alternative text manually, not only which validator they use; how they handle the language settings and hidden text of translated versions; and how they make sure an update does not undo the work. The answers tell you more than a sample file, and the same thinking applies to checking a supplier’s quality before you hire them.
How DEMA Solutions makes PDFs accessible
Our PDF remediation and PDF/UA accessibility service follows the sequence in this guide. We audit the PDF for structure, reading order, contrast, tables, images, links, forms and metadata; where appropriate we rebuild or correct the source in Word or InDesign, otherwise we remediate the PDF tags directly; we add headings, lists, table structures, alternative text, artifacts, language settings and navigation; we check the document with accessibility tools and review how content is exposed to assistive technology; and we deliver it with the agreed validation evidence.
The difference is the connection with translation and layout. Our in-house DTP team already works in the source files of manuals, catalogues and reports, so accessibility can be built in during multilingual desktop publishing instead of being added afterwards, and in multilingual projects the checks are repeated on the final file in each target language. Translations follow our ISO 17100 certified process, with a second qualified linguist revising every translation. Where documents also need to be easier to understand, our plain language service rewrites them, and our accessibility and inclusive language services bring these together. Our teams work in Italy, Serbia and Spain.
Where TUBE fits
For manuals and catalogues republished in several languages with every update, TUBE keeps the language of each edition under your control. Your glossary and translation memory control machine translation, every approved translation goes into a memory you own and can export, and leverage reporting shows how much of each update comes from text you have already approved.
Frequently asked questions
Build the source with real headings, lists, tables, alternative text, a title and a declared language, export a tagged PDF, correct tags, reading order and artifacts where needed, then test with an automated PDF/UA checker and a manual review. Without a source, the structure is added to the PDF through remediation.
PDF/UA (ISO 14289) is a technical standard for the PDF file: tagging, artifacts, fonts, metadata and language. WCAG describes accessible content in general, such as contrast and meaningful links, and reaches PDFs in Europe through EN 301 549. Most organisations need to meet both.
No. Word can export a tagged PDF, but it is only as accessible as the document behind it. Headings made with font formatting, images without alternative text and tables drawn with tabs all carry through.
Only partly. Automated checkers test measurable conditions such as tags, fonts, metadata and language. They cannot judge whether alternative text is meaningful or the reading order makes sense, so a manual review is always needed.
If the document has to be accessible, yes. Each translated PDF has its own language setting, reading order, alternative text and metadata, and translation and layout changes often break them, so each version should be checked on its own.
Fix the source whenever the document will be updated or translated, so the structure carries into every new version. Remediating the PDF suits static documents with no usable source.
The target standard, documents and formats, availability of source files, languages, update frequency, who approves alternative text for technical images, and the validation evidence expected with each delivery.
Make your multilingual documents accessible
If your manuals, catalogues or reports need to be accessible in several languages, send us a sample document and tell us which languages you publish in. We will review its structure, explain what it needs to meet PDF/UA and WCAG, and plan the work around your translation and update cycle.
How can we help?
Tell us what you need and we’ll get back to you with the solutions.