What EN 301 549 requires for PDF documents

General orientation, not legal advice. The binding sources are the text of the standard, the Official Journal of the EU and the national implementing laws.

What the standard covers

EN 301 549 (“Accessibility requirements for ICT products and services”) is published jointly by the European standardisation organisations ETSI, CEN and CENELEC. It sets accessibility requirements for almost every kind of digital technology, from hardware and software through websites, mobile apps and documents to self-service terminals and support services. For web, documents and software it adopts the level A and AA success criteria of WCAG, some with adapted wording.

If you are responsible for documents, four clauses concern you most. Clause 9 covers web pages and content embedded in web pages and rendered with them. Clause 10 deals with non-web documents such as downloadable PDFs, office files or e-books. Clause 11 covers software, including PDF readers and other applications that present documents. Requirements for authoring tools were in clause 11.8 of V3.2.1 and have moved to clause 5.10 in V4.1.1.

Clause 12 is easy to overlook. Called “Documentation and support services”, renamed in V4.1.1 to “Information about products and services”, it requires product information, manuals and support services to be accessible themselves. If you ship manuals or product information as PDFs, those files are covered too.

V3.2.1 or V4.1.1

The standard has been revised several times. Two versions are relevant at the moment.

A new version does not take effect by itself. The presumption of conformity only arises once the European Commission publishes the reference in the Official Journal of the EU, and until then V3.2.1 remains the authoritative reference. According to the foreword of V4.1.1, 30 November 2026 is the date of latest announcement at national level. When the Commission will cite it had not been confirmed at the time of writing.

For new PDFs we recommend working to V4.1.1 and WCAG 2.2 now. Reworking documents later costs more.

When a PDF counts as a non-web document

According to clause 10.0, clause 10 applies to documents that are not web pages, are not embedded in web pages, or are provided with a web page but not rendered together with it. That is the classic PDF download: an invoice, contract, annual report or form that users download and open in a reader. Content embedded in a web page and rendered with it falls under clause 9 instead.

Clause 10 explicitly also applies to documents protected by digital signatures, encryption, password protection or watermarks once they are presented to the user. A protected PDF has to be just as accessible as an unprotected one.

Where clause 10 departs from WCAG

Most WCAG criteria carry over to clause 10 unchanged. A few are adapted to the situation of a single document.

• Bypass Blocks (2.4.1) and Multiple Ways (2.4.5): marked “Void” in both versions, so not applicable to documents. The standard explains that the web requirements relate not to single documents but to rare “sets of documents”. Bookmarks and headings are still good practice.
• Consistent Navigation (3.2.3) and Consistent Identification (3.2.4): also “Void” in V3.2.1. V4.1.1 makes them binding, but only within a set of non-web documents, meaning related documents by the same author that are published together and refer to each other.
• Page Titled (2.4.2): becomes “document titled”. V3.2.1 explicitly allows a descriptive file name to count as the title. For PDFs a title in the metadata is still the safe route, not least because PDF/UA requires it anyway.
• Parsing (4.1.1): in V3.2.1 only relevant for documents whose markup is directly exposed to assistive technologies; the standard gives HTML, ODF and OOXML as examples. V4.1.1 drops the criterion, as WCAG 2.2 does.
• Reflow (1.4.10): the notes were rewritten for documents. Content that needs a two-dimensional layout, such as data tables, diagrams or presentations, remains exempt.

V4.1.1 brings the new WCAG 2.2 criteria into clause 10, among them Focus Not Obscured, Target Size, Consistent Help, Redundant Entry and Accessible Authentication. It also adds clause 10.7: a document must not block reader modes that present it according to user preferences, or override documented platform accessibility settings, unless this is essential to the information or function of the document. Which WCAG criteria matter for PDFs in practice is covered in WCAG 2.2 for PDF documents.

PDF/UA is not mandatory

EN 301 549 does not require PDF/UA. It sets requirements for the outcome, not the file format. Even so, PDF/UA is the proven technical route to meeting clause 10 in PDFs. Tags, language, title, alternative text and reading order underpin almost every success criterion. How the two sets of rules work together is explained in PDF/UA vs. WCAG.

The standard under the EAA and the Web Accessibility Directive

Neither the European Accessibility Act nor the Web Accessibility Directive contains detailed technical rules for PDFs. Both provide that compliance with harmonised standards whose references are published in the Official Journal gives a presumption of conformity with the respective requirements (Article 15 of Directive (EU) 2019/882, Article 6 of Directive (EU) 2016/2102).

For websites and mobile applications of public sector bodies, EN 301 549 V3.2.1 is cited in the Official Journal. National laws such as Austria’s Web Accessibility Act (WZG) or Germany’s BITV 2.0 build on it, and downloadable PDFs on public sector websites are measured against clause 10 in practice.

For the private sector (EAA and national laws) no harmonised standard has been cited in the Official Journal yet. Businesses and market surveillance authorities still use EN 301 549 as their benchmark. Citation of V4.1.1 would change that.

Where to begin

Sort your PDFs first: downloads fall under clause 10, manuals and product information under clause 12 as well. Then check tags, title, language and fonts with a PDF/UA check, PAC or veraPDF. What the typical messages mean is explained in Common PAC and veraPDF errors. Contrast, alternative text, link text and reading order have to be checked by hand; our accessible PDF checklist covers these points.

Errors are best fixed in the template. For legacy files without a source, EasyPDFUA can add a basic structure with tags, title, language and links. Headings, tables and alternative text remain manual work.

Keep a written record of the test results and the version of the standard you used. Public sector bodies must also publish an accessibility statement; see Accessible PDFs in the public sector. An EasyPDFUA report is not a confirmation of conformity with EN 301 549. It is a technical inventory from which further review can start.

Frequently asked questions

Which clause of EN 301 549 applies to PDFs?

Clause 10, for downloadable PDFs. Content embedded in a web page and rendered with it falls under clause 9. PDF readers and other software are covered by clause 11, product documentation by clause 12.

Does EN 301 549 V4.1.1 already apply?

Not yet. ETSI published V4.1.1 in September 2026, but the presumption of conformity only arises once it is cited in the Official Journal of the EU. That was still pending in October 2026, so V3.2.1 remains the reference for now.

Does EN 301 549 require PDF/UA?

No. The standard sets requirements for the outcome, not the format. PDF/UA is, however, the proven technical way to meet the clause 10 criteria in PDF documents.

Which WCAG criteria do not apply to PDFs?

Bypass Blocks (2.4.1) and Multiple Ways (2.4.5), among others, which clause 10 marks as not applicable to documents. Under V4.1.1, Consistent Navigation and Consistent Identification only apply within a set of related documents. Criterion 4.1.1 Parsing is dropped in V4.1.1.