A standard about construction
A PDF is first of all a drawing: characters placed at coordinates on a page. Nothing in that drawing says that a bold line is a heading, that three aligned columns form a table, or that the text at the bottom of the page should be read after the text at the top. A sighted reader puts all of this together at a glance. A screen reader only knows what the file declares.
PDF/UA, for PDF Universal Accessibility, is the international standard ISO 14289. It sets out what the file must declare to be rendered correctly. It is a standard about construction: it describes the form of the file, not the experience of the person reading it. That distinction governs everything else, and most misunderstandings about the standard come from forgetting it.
What PDF/UA is, and what it is not
PDF/UA is the technical standard for accessible PDFs. It says how to tag content, declare the reading order, state the language, and attach an alternative to every image that carries meaning. A file that follows it gives assistive technologies everything they need to work.
PDF/UA is not, however, a guarantee that the document will be understood. The standard does not deal with contrast: in a single note, it defers to the Web Content Accessibility Guidelines (WCAG). It requires an image to have an alternative, not that the alternative be accurate. It governs the sequence of heading levels, not whether what was made a heading deserved to be one.
Nor is PDF/UA, in Europe, a legal obligation. The texts name WCAG, which is the subject of our article PDF/UA and WCAG: two standards, two questions. The standard is nonetheless necessary: WCAG cannot be met in a PDF unless the PDF is built correctly, and PDF/UA is what says how.
PDF/UA-1 or PDF/UA-2: which one to aim for?
The standard has two parts. PDF/UA-1 (ISO 14289-1, 2014 edition) applies to files built to the PDF 1.7 specification. PDF/UA-2 (ISO 14289-2, published in March 2024) applies to PDF 2.0 files, and makes use of their new structure types.
The choice therefore follows, first, the PDF version your production chain actually outputs, not how recent the standard is. It then follows the tooling: support for PDF/UA-2 is growing in validators and remediation software, but it is not yet universal. An organisation that produces PDF 1.7 today and whose checking tools validate PDF/UA-1 has no reason to switch on principle; one that is renewing its production chain should raise the question in its requirements.
Good news for anyone who wants to go to the source: the PDF Association makes the text of both parts available free of charge, for individual use.
What the standard requires in the file
Without going through the standard clause by clause, its requirements fall into a few families:
- Tagging. All real content belongs to a tag tree, with the most semantically accurate tag: heading, paragraph, list, table, figure.
- Artifacts. Anything that is only decoration (rules, backgrounds, repeated page numbers) is marked as such, so that the screen reader does not announce it.
- Reading order. Content is tagged in its logical reading order, which is not always the display order: a right-hand column, a box-out, a footnote.
- Alternatives. Every image that carries meaning has a text alternative.
- Tables. Header cells are identified as such, so that a data cell can be rendered together with its headings.
- Language and title. The language is declared, and the document has a title in its metadata.
- Meaning carried by form. No information is carried by colour, contrast or layout alone without the tagging reflecting it.
- Forms and links. Fields and links are tagged and described.
- Identification. The file declares in its metadata which part of the standard it claims.
The Matterhorn Protocol: what a validator can establish
A standard is something you read; it does not check itself. The PDF Association therefore published the Matterhorn Protocol, which breaks PDF/UA-1 down into 31 checkpoints and 136 failure conditions: the list of every way a file can fall short of the standard.
Each failure condition is classified according to whether software can decide it alone or whether it needs human review. This is the protocol’s most valuable contribution, and the one most often forgotten: it states in black and white that a validator, however good, cannot declare a PDF conformant on its own. It establishes missing tags, a missing language, an absent alternative. It cannot say whether the tag applied is the right one, whether the reading order makes sense, or whether the alternative describes the image.
Validating a PDF: the file first, the report second
Two free validators are the reference: PAC, and veraPDF, open-source software that covers both PDF/UA-1 and PDF/UA-2. Their report is indispensable, but it often misleads those who read it first.
Experience has taught us to start with the file. Which software produced it? Is it the accessible export, or a PDF printout of the source document sent by mistake? Is the file tagged at all, is its language declared? A report that flags every text object as “untagged” does not describe a hundred defects to fix one by one: it describes a file that was never tagged, and the answer is to go back to the right source. This reading takes thirty seconds and saves days of pointless remediation.
Then comes the report, line by line. And after it, listening: running the document through a screen reader, or through the reading preview of a remediation tool. That is where you hear what no validator reports. On catalogues that were tagged and declared conformant, we have found alternatives beginning with “Image of…” (redundant: the screen reader already announces an image) and split prices read as “2”, “9”, “€”, “,70”, which a blind user heard as four unrelated fragments.
Producing PDF/UA at scale, on variable-data documents
Everything above applies to one document. The problem changes in nature when the document is not written but generated: bank statements, payment notices, invoices, payslips, contracts, produced by the hundreds of thousands from the same template with different data in every one.
In a chain of this kind, fixing files one at a time makes no sense. Tagging is set in the template, once, and every document produced inherits it, with its qualities and its defects alike. Three consequences follow, and they are the heart of the matter.
Validate the template on data that puts it to the test. A template that conforms on the test set can fail on the real document: a transaction table that breaks across two pages and loses its headers, an empty conditional block that leaves an orphaned heading, a language that changes with the customer. The validation set must contain these edge cases, not just the nominal case.
Check production by sampling. Nobody runs a million documents through a screen reader. You validate a large sample automatically, listen to a small sample chosen to cover the template’s variants, and track the measurement over time.
Revalidate at every change. An added legal notice, a moved block, a new offer variant: any change to the template can break the reading order of every document it produces. A template’s conformance is proven at every version, like its accuracy, by automated comparison before going into production.
This is exactly the discipline a migration of a document composition platform calls for, and it has been our trade for twenty-five years. Making mass production accessible is not a file remediation project: it is an industrialisation project, carried out inside the existing chain rather than alongside it.
Frequently asked questions
Is PDF/UA the same thing as an accessible PDF?
No. PDF/UA describes how the file must be built so that assistive technologies can render it: tagging, reading order, language, alternatives. A PDF can follow that construction and still be hard to understand, for instance if its text alternatives describe nothing or its contrast is too low. PDF/UA is a condition for an accessible PDF, not a guarantee of one.
Is PDF/UA mandatory?
None of the texts we have read requires it: not the European Accessibility Act, not the EN 301 549 standard, not the French RGAA. What the law requires is WCAG. PDF/UA is still necessary in practice, because it is the technical way to build a PDF that assistive technologies can render. The new version of EN 301 549, published in September 2026, does cite it, in an informative note, as the technical standard that helps achieve this.
Is a tagged PDF enough?
No. Tagging is the first requirement of PDF/UA, not the last. A PDF can have a complete tag tree and still have badly nested headings, tables without headers, empty alternatives, or prices split into fragments that the screen reader announces one by one. Whether tags are present can be checked in seconds; whether they are right takes a review.
How can I check a PDF for free?
Two free validators are the reference: PAC, and veraPDF, which is open source. They find what a machine can decide. Before reading their report, it is worth looking at the file itself: which software produced it, whether it is tagged at all, whether its language is declared. And after the report, the document still has to be listened to with a screen reader, which no validator does for you.
Can an existing PDF be made accessible automatically?
Partly. Tagging, reading order and table structure can be largely automated, and that is essential as soon as there is volume. What cannot be automated: deciding whether an alternative really describes the image, whether a heading hierarchy follows the logic of the document, whether a table still makes sense read from left to right. For documents produced in series, it is also more effective to fix the template that generates them than each file.