The law requires WCAG. PDF/UA is necessary, but not sufficient.
Two standards come up as soon as accessible PDF is mentioned, and they are often presented as two options to choose between. They are not. They do not answer the same question, they are not cited by the same texts, and a document that aims for one without the other almost always fails somewhere.
Our position fits in two sentences. The law requires WCAG. PDF/UA is necessary, but not sufficient. The rest of this article explains why, based on the texts themselves.
Two standards, two questions
PDF/UA (ISO 14289) answers the question: is the file well built? Is its content tagged, in the right order, with a declared language and an alternative for every image? It is a standard specific to the PDF format, which we cover in detail in PDF/UA: what the standard requires, and what it does not guarantee.
WCAG, the Web Content Accessibility Guidelines published by the W3C, answer another question: does the person understand? Does the text stand out from its background, does the alternative really describe the image, does the link text keep its meaning out of context? Written for the web, they apply to documents through the European standard EN 301 549 and, in France, through the RGAA, the national accessibility framework.
The first question concerns the form of the file, and much of the answer comes from a validator. The second concerns meaning, and it calls for human judgement.
Where they overlap, where they diverge
| Requirement | PDF/UA | WCAG |
|---|---|---|
| Structured, tagged content | required, with the most semantically accurate tag | required: information and relationships must be programmatically available |
| Logical reading order | required | required |
| Text alternative for images | presence required | relevance required |
| Document language | required | required |
| Information conveyed by colour or formatting alone | prohibited unless reflected in the tagging | prohibited |
| Text contrast | not addressed (a mere pointer to WCAG in a note) | required, with numerical thresholds |
| Flashing | prohibited | regulated |
| Relevance of link text and headings | not addressed | required |
| Declaration of the standard in the file’s metadata | required | not applicable |
The table says what matters. Where the two standards overlap, PDF/UA requires the element to exist and WCAG requires it to serve. Where they diverge, it is almost always on what calls for judgement: PDF/UA, which does not deal with colour, lets through a 2:1 contrast that WCAG rejects; an alternative reading “image1.png” satisfies PDF/UA, since it exists, while telling nobody anything.
What the texts say
We read the texts themselves, not their summaries. Here is what they say about documents.
| Text | WCAG version | Place of PDF/UA |
|---|---|---|
| Directive (EU) 2019/882, known as the European Accessibility Act | no version cited by the directive itself | none |
| EN 301 549 V3.2.1, European standard in force, clause 10 “non-web documents” | WCAG 2.1, criterion by criterion | none |
| EN 301 549 V4.1.1, published in September 2026, effective once cited in the Official Journal | WCAG 2.2 | an informative note: PDF/UA-1 and PDF/UA-2 “are the technical standards for accessible PDFs” and “would be useful” in meeting EN 301 549 |
| RGAA 4.1.2 (France), criterion 13.3 | WCAG 2.1 | none; PDF is listed among formats “whose compatibility is recognised” |
Three points deserve emphasis.
Clause 10 of EN 301 549 explicitly covers downloadable documents. Its requirements apply to documents that are not web pages, including those provided with a web page without being embedded in it: the PDF of a statement, an invoice or terms and conditions offered for download.
None of these texts requires PDF/UA. It is sometimes said that PDF/UA became a mandatory format in 2025; that is not what the texts say. The only one that cites it, the new version of EN 301 549 published in September 2026, does so in an informative note, as a useful means and not as a requirement.
The reference is moving. The RGAA is being overhauled, with a version 5 announced for the end of 2026, and EN 301 549 moves to WCAG 2.2 in its version 4.1.1, published in September 2026. An accessibility programme launched today has every interest in aiming for 2.2, so as not to rework its documents in two years’ time.
As for the timetable, the directive has applied since 28 June 2025. For the services it covers, office files published before that date are excluded from its requirements relating to websites and applications: a document published since falls within them. Our document accessibility page details the scope of the directive, the sectors concerned and how it fits with the RGAA.
This summary is provided for information only and does not constitute legal advice.
Aiming for both: structure first, judgement second
In practice, PDF/UA and WCAG are not handled one after the other as two projects. They fall into an order.
Structure first. Tagging, reading order, language, table headers, artifacts: everything PDF/UA requires, and that a validator can largely check. Without this foundation, no WCAG criterion can be met in a PDF: a screen reader cannot render what the file does not declare.
Judgement second. Do the alternatives describe the image in its context? Does the heading hierarchy follow the logic of the document? Does a table still make sense read cell by cell? Does the contrast hold, including on the brand’s coloured backgrounds? This part cannot be automated, and it is what makes the difference between a conformant document and a usable one.
Tooling is not an alternative to expertise: it is its precondition. It absorbs the volume so that judgement can concentrate where it cannot be replaced. On documents produced in series, that judgement is exercised once, on the template, and not on each of the documents it produces.
Proving and declaring conformance
A PDF can declare in its metadata that it claims PDF/UA. The standard provides for this, and immediately states that the declaration is not, on its own, enough to establish conformance. A file that announces itself as PDF/UA is therefore not necessarily so: it is a claim, not proof.
Proving conformance takes three pieces:
- a validator’s report, covering what a machine can decide;
- a human review, recorded, covering the rest: relevance of the alternatives, logic of the structure, contrast, comprehension;
- for mass production, a description of the method: the dataset used to validate the template, the size and rule of the sample checked in production, revalidation at every version.
It is this whole, and not a box ticked in export software, that lets you answer a buyer, an auditor or a customer who asks whether your documents are accessible.
Frequently asked questions
Is a PDF/UA-conformant PDF also WCAG-conformant?
Not necessarily. PDF/UA guarantees that the file is built to be rendered by assistive technologies; WCAG additionally requires the content to be perceivable and understandable. A PDF can conform to PDF/UA with insufficient contrast, which the standard does not address, or with text alternatives that are present but meaningless. The reverse is also true: WCAG cannot be met in a badly built PDF.
Should we aim for both PDF/UA and WCAG?
Yes. The law requires WCAG: it is what the European standard EN 301 549 and the French RGAA refer to. PDF/UA is the technical way of achieving it in a PDF. Aiming for PDF/UA alone produces documents that conform but are sometimes unusable; aiming for WCAG without PDF/UA means seeking understanding without the structure that makes it possible.
Which version of WCAG should we aim for?
Version 2.1, level AA, is today the reference of the applicable texts: EN 301 549 in the version cited so far in the Official Journal (V3.2.1) and the RGAA 4.1.2 both refer to it. The new version of EN 301 549, V4.1.1, published in September 2026, moves to WCAG 2.2; it will only confer a presumption of conformity once cited in the Official Journal. Aiming for 2.2 now costs little on documents, since the added criteria concern interaction (focus, targets, input, authentication), and it avoids redoing the work later.
Are documents published before June 2025 affected?
For the services covered by the European Accessibility Act, office files published before 28 June 2025 are excluded from its requirements relating to websites and applications. Conversely, a document published since that date on the website or application of a covered service falls within scope. Bodies subject to the French RGAA come under older, separate rules.
How do you handle thousands of statements or invoices?
In the template that produces them, not file by file. For variable-data documents, the accessible structure is set once in the composition template, validated on a dataset that tests its edge cases, then checked in production by sampling. Every change to the template calls for a new validation, just as it does for its accuracy.