Skip to content
wcagc
←Back to blog
EN 301 549PDFdocumentsEAAWeb Accessibility Directive

EN 301 549 documents: what Chapter 10 requires

Chapter 10 of EN 301 549 applies WCAG to PDFs, Word files and other non-web documents. Which clauses change, what V4.1.1 adds, and how to test.

P

Pavel Charkasau

EN 301 549 handles documents in Chapter 10, "Non-web documents". It covers the files people download or receive rather than view inside a web page: PDFs, Word and spreadsheet files, presentations, emails. For each of them it applies the WCAG Level A and AA success criteria, with the word "web page" swapped for "non-web document" (ETSI EN 301 549 V4.1.1, clause 10.0). In the version cited today, v3.2.1, that means WCAG 2.1. In V4.1.1, published in September 2026, it means WCAG 2.2.

A handful of criteria are dropped or reworded because they only make sense across a website. Bypass blocks and multiple ways are "Void" for single documents. Document title depends on the file format. Reflow applies only where the viewer can reflow. V4.1.1 also adds one clause that has no WCAG equivalent: 10.7, which says a document must not block the user's preference settings in the reader.

For a downloadable PDF on a site under the EAA or the Web Accessibility Directive, Chapter 10 is the part of EN 301 549 it is measured against.

What counts as a non-web document in EN 301 549?

Clause 10.0 says the chapter applies to documents that are not web pages, are not embedded in web pages, and are "provided with web pages but are neither embedded nor rendered together with the web page from which they are provided". The standard adds a plain gloss in brackets: "the present clause applies to downloadable documents" (ETSI EN 301 549 V4.1.1, clause 10.0).

Note 1 lists examples: letters, spreadsheets, emails, books, pictures, presentations and movies opened in a reader, editor or media player. Two other notes matter when you scope an audit:

  • A document is still in scope when it is protected with a digital signature, encryption, a password or a watermark, once it is presented to the user (Note 8). A signed contract PDF gets no exemption for being signed.
  • ISO 14289-1:2014 and ISO 14289-2:2024, the PDF/UA standards, "would be useful in meeting EN 301 549" (Note 11).

The line between clause 9 and clause 10 is about rendering, not file type. A PDF shown inside the page in an embedded viewer as part of the page is clause 9. The same PDF behind a "Download" link is clause 10.

Which EN 301 549 document requirements differ from WCAG?

Most of Chapter 10 is a one-line pointer: "the non-web document shall satisfy the WCAG 2.2 Success Criterion" with the matching number. The interesting parts are the exceptions. Here they are for V4.1.1, compared with v3.2.1 (ETSI EN 301 549 v3.2.1, clause 10):

ClauseWCAG criterionIn v3.2.1In V4.1.1
10.2.4.12.4.1 Bypass blocksVoidVoid
10.2.4.22.4.2 Page titledApplies; a descriptive file name counts as a titleApplies where the format has an editable Title attribute
10.2.4.52.4.5 Multiple waysVoidVoid
10.3.2.33.2.3 Consistent navigationVoidApplies within a set of non-web documents
10.3.2.43.2.4 Consistent identificationVoidApplies within a set of non-web documents
10.3.2.63.2.6 Consistent helpNot presentApplies within a set of non-web documents
10.4.1.14.1.1 ParsingApplies to markup-based documentsVoid (removed from WCAG 2.2)
10.7NoneNot presentUser preferences for non-web documents

Two of those rows, and one rule outside the table, need explaining.

The "set of non-web documents" rows. V4.1.1 defines a set narrowly. The documents must share a common purpose, come from the same author or organisation, be published together, and all refer to each other by name or link. Bundling old documents does not make a set (ETSI EN 301 549 V4.1.1, clause 3.1). The definition comes from the W3C's WCAG2ICT Group Note (W3C). A single annual report PDF is not a set. A ten-volume product manual whose volumes cross-reference each other probably is, and its repeated navigation and help sections now have to stay in the same relative order.

Document titled. In v3.2.1, Note 1 said the name of a document "is a sufficient title if it describes the topic or purpose", so pricing-2026.pdf could pass. V4.1.1 drops that note. Clause 10.2.4.2 now applies where the format "supports a programmatically determinable 'Title' attribute that is editable using common authoring tools", and PDF, Word and PowerPoint all have one. In practice: fill in File > Properties > Title, and in a PDF set the viewer to show the title instead of the file name.

Reflow. Clause 10.1.4.10 applies only where the user agent can present content at a width of 320 CSS pixels. Note 4 says outright that if a document type and its viewers don't support reflow, "it may not be possible for a document of that type to meet this success criterion".

Section 508 differs slightly. Its E205.4 exempts non-web documents from 2.4.1, 2.4.5, 3.2.3 and 3.2.4 (U.S. Access Board). V4.1.1 now applies the last two to sets of documents, so a team working to both should follow the European reading.

What does V4.1.1 add for documents?

The WCAG 2.2 AA additions come across: 10.2.4.11 Focus not obscured (minimum), 10.2.5.7 Dragging movements, 10.2.5.8 Target size (minimum), 10.3.2.6 Consistent help, 10.3.3.7 Redundant entry and 10.3.3.8 Accessible authentication (minimum). For a report PDF with no drag interactions and no login, most of them are simply met: Note 10 of clause 10.0 says a criterion whose feature doesn't occur in the document is satisfied.

Fillable forms are where they bite. A PDF form with small checkboxes now has a target size requirement (24 by 24 CSS pixels, with the same spacing, inline and equivalent exceptions as WCAG). A multi-page PDF form that asks for your address on page 1 and again on page 4 runs into Redundant entry.

The genuinely new clause is 10.7. A document "shall not block the user agents mode(s) of operation that present the document according to user preference settings", or override the user's platform accessibility settings, unless that is essential (ETSI EN 301 549 V4.1.1, clause 10.7). In plain terms: if the reader app offers a high-contrast or replace-document-colours mode, your file shouldn't be built so that mode can't work.

Does the EAA or the Web Accessibility Directive require accessible documents?

Both do, through EN 301 549.

For public sector bodies, Annex ZA of EN 301 549 maps the standard to the Web Accessibility Directive (EU) 2016/2102. Table ZA.1 lists "documents, including forms, that are downloadable from web pages" among the things it applies to (ETSI EN 301 549 V4.1.1, Annex ZA). The Directive has one document-specific exemption: "office file formats published before 23 September 2018, unless such content is needed for active administrative processes" (Directive (EU) 2016/2102, Article 1(4)(a)). A 2015 archived report can stay as it is. A 2015 application form that people still fill in cannot.

For private companies under the European Accessibility Act, the new Annex ZB routes documents through clause 12. Where the EAA asks for product information, or "electronic information needed in the provision of the service", to be perceivable, operable, understandable and robust, the mapped clauses 12.1 and 12.2 require clause 10 for non-web documents (ETSI EN 301 549 V4.1.1, Tables ZB.1 and ZB.4). A downloadable user manual is a typical case.

One caveat on versions. The Official Journal citation that gives a presumption of conformity still points to v3.2.1, through Commission Implementing Decision (EU) 2021/1339, and that citation is under the Web Accessibility Directive. The Commission's AccessibleEU centre confirmed on 7 September 2026 that v3.2.1 remains the reference until V4.1.1 is formally cited (AccessibleEU). The Annex ZB explainer has the detail.

How do you test a document against Chapter 10?

Use clause A.2 and Annex C. Table A.2 in V4.1.1 lists every clause 10 requirement with a condition and a matching Annex C test, from C.10.1.1.1 to C.10.7. The tests are inspections. C.10.2.4.2, for example, has two preconditions (it is a document; the format supports an editable Title) and one check: "the non-web document has a title that describes the name, topic, or purpose".

In practice, for a PDF, the work splits like this:

  1. Machine checks. Is the file tagged? Is a document language set? Is there a Title in the metadata? Do figure tags carry alt text? Our PDF accessibility checker covers those four.
  2. Human checks. Is the tag order the order a person reads the page? Does the alt text say what the chart shows, or just "Chart 3"? Are table header cells marked, and do they make sense read aloud? No validator judges these.
  3. Viewer checks. Open the file with a screen reader (for example NVDA with Acrobat Reader) and with the reader's replace-colours setting on. That second one is your 10.7 check.

I don't have a reliable figure for how much of Chapter 10 automation covers. For web pages, Deque's study found automated testing identified 57% of issues by volume, against the older 20 to 30% estimate based on success criteria (Deque). I would not assume documents do better. Reading order alone is a manual job on every multi-column layout. Our guide to making a PDF accessible walks through the tagging and repair steps.

Should that document be a PDF at all?

My view: the cheapest Chapter 10 fix is often to not publish a document. If the content is a policy, a price list or a how-to, an HTML page is easier to make accessible, easier to keep current, and gets tested by the same pipeline as the rest of your site. Keep PDFs for what needs a fixed layout or a signature, such as contracts, statements and forms that must be printed, and give those the full inspection.

Whatever you keep, list it. Your accessibility statement is where you say which documents are known not to conform and what the accessible alternative is.

Frequently asked questions

What does Chapter 10 of EN 301 549 cover?

Chapter 10 of EN 301 549 covers non-web documents: files that are downloaded or opened outside a web page, such as PDFs, Word files, spreadsheets, presentations and emails. It applies the WCAG Level A and AA success criteria to them, with a few criteria marked Void or reworded.

Is a PDF on my website covered by clause 9 or clause 10?

A PDF behind a download link is covered by clause 10. Clause 9 applies only to documents that are embedded in a web page and rendered together with it.

Does EN 301 549 require PDF/UA?

No. Note 11 of clause 10.0 in V4.1.1 says ISO 14289-1 and ISO 14289-2 "would be useful in meeting EN 301 549", but the requirements themselves are the clause 10 success criteria.

Which WCAG criteria don't apply to documents in EN 301 549?

Bypass blocks (2.4.1) and Multiple ways (2.4.5) are Void for documents in both v3.2.1 and V4.1.1. Parsing (4.1.1) is Void in V4.1.1 because WCAG 2.2 removed it, and Consistent navigation and Consistent identification apply only within a narrowly defined set of documents.

Are old documents exempt?

Under the Web Accessibility Directive, office file formats published before 23 September 2018 are exempt unless they are needed for active administrative processes. EN 301 549 itself has no date-based exemption.

Check the pages that link to your documents

A document audit is only half the job, because clause 9 still applies to the page that links to it. Run a free scan to find the machine-detectable WCAG issues on your pages, then run your most-downloaded PDFs through the checker and do the human checks above. Full conformance needs a person with a screen reader for both.

Pavel Charkasau, founder, wcagc.com. Last updated 25 September 2026.

Sources