WCAG passes, your PDFs still fail

A team spends a quarter on accessibility. Contrast ratios fixed, focus order sorted, ARIA landmarks in place. axe and Lighthouse come back clean, the external audit signs off, and everyone moves on.

Then someone opens the monthly statement the app emails out, feeds it to a screen reader, and gets a wall of undifferentiated text with no headings, no table structure, and no way to tell a column label from a value.

Nothing regressed. The audit was never looking at that file.

The audit stops at the link

Automated web accessibility checkers evaluate a rendered DOM. axe, Lighthouse, WAVE and Pa11y walk the accessibility tree the browser builds from your markup. A link to statement-2026-07.pdf is, to all of them, a link: they can tell you whether it has discernible text, and that is where their involvement ends. The bytes on the other side are a different format with a different structure model, and no DOM-based checker opens them.

Some auditors flag linked documents as a manual review item. Many reports do not mention them at all, which is how a product ships with an accessible interface and inaccessible output for years without anyone noticing.

Two clauses, not one

The separation is not an oversight. It is written into the standard.

EN 301 549 is the European accessibility standard that the European Accessibility Act (Directive (EU) 2019/882) leans on, and it splits its requirements by what kind of thing is being made accessible:

• Clause 9, Web, which adopts WCAG 2.1 level AA for web content.
• Clause 10, Non-web documents, which applies the equivalent success criteria to documents: PDFs, office files, anything you produce and hand over rather than serve as a page.
• Clause 11, Software, for non-web applications.

A conforming website satisfies clause 9. It says nothing about clause 10. If your product emits invoices, statements, contracts, reports, tickets or certificates, those are clause 10 material, evaluated on their own.

The Act has applied since 28 June 2025, and the sectors it covers include e-commerce, banking and financial services, transport ticketing, telecoms and e-books, along with the product documentation and customer support around them. Enforcement so far has been about market surveillance, formal notices and court orders rather than fines, but the direction is consistent across the member states that have started.

PDF/UA is the document-side spec

PDF/UA-1 (ISO 14289-1) is what clause 10 conformance for PDF is normally demonstrated against. It is not a competing standard to WCAG. It is the technical answer to a question WCAG does not need to ask, because the web already has an answer to it: where does the structure live?

HTML carries structure in the markup. <h2> is a heading because the element says so. Assistive technology reads the tree the browser builds and gets headings, lists, tables and labels for free.

PDF has no such guarantee. At its core PDF is a page description format: a content stream that says place this glyph at this coordinate in this font at this size. A heading in a PDF is, by default, some text that happens to be 24 point and bold. There is nothing in the file that says it is a heading, no relationship between a table cell and its column header, no notion that these five lines are a list, and no reliable reading order beyond the order the generator happened to paint things in.

Tagging is the layer that fixes this. A tagged PDF carries a structure tree alongside the page content: H1, P, Table, TH, TD, L, LI, Figure, each pointing at the marked content it describes. Screen readers follow that tree. PDF/UA specifies what the tree must contain and how it must relate to what is painted on the page.

Two consequences catch people out:

• The reading order is the structure tree's order, not the visual layout and not the order things were drawn. A two-column layout that looks correct can read straight across the gutter.
• Content that is not real content still has to be declared. Decorative rules, background images, repeated header and footer furniture: PDF/UA requires these to be marked as artifacts, not merely left untagged. Untagged content is a failure, not a neutral omission.

What survives HTML to PDF, and what does not

If your PDFs come out of a browser or an HTML rendering engine, the question is whether that engine carries your DOM structure through into a structure tree or throws it away and paints pixels.

Plenty of pipelines throw it away. The output looks identical, opens fine, and prints correctly. What is missing is invisible in every viewer that is not a screen reader:

• Headings become large text.
• Tables become ruled lines with numbers between them.
• alt attributes vanish, because there is nothing in an untagged PDF to attach them to.
• Lists become bullet glyphs followed by paragraphs.
• Form fields lose their labels.

Even when an engine does tag, the tags are only as good as the markup you fed it. A page built out of <div> soup with visual styling produces a structure tree of undifferentiated P elements, correctly, because that is what you described. Layout tables produce table structure that a screen reader will announce as a table. alt="" on an image you meant as decorative does not automatically become an artifact.

Semantic HTML is not a nice-to-have upstream of PDF generation. It is the input the structure tree is built from.

What a validator can prove, and what it cannot

This is the part most vendor copy skips.

The PDF Association's Matterhorn Protocol translates ISO 14289-1 into a testing model: 31 checkpoints containing 136 failure conditions. They do not split evenly.

How a condition is checked	Count
By software	89
By a human reading the document	45
No determined method	2
Total	136

So automated PDF/UA validation, including veraPDF running its PDF/UA-1 profile, covers roughly two thirds of the standard. That two thirds is worth having: it is the mechanical, tedious, easy-to-regress part, and it is the part a build pipeline can gate on. It catches untagged content, a missing document title, missing alternate text, structure that contradicts itself, metadata that does not match.

It cannot tell you:

• whether the alt text is a useful description or the string image,
• whether the reading order makes sense to a human,
• whether headings describe a real document hierarchy or were picked for size,
• whether a table's headers are the right headers.

A file that passes machine validation and has alt text reading chart1.png throughout is a file that passes machine validation. Any tool, ours included, that describes a green validator run as accessibility is overstating what it measured.

The useful framing is a floor, not a finish line. Machine validation is a regression gate that makes the remaining human review small and targeted instead of a full manual pass on every document.

A workable order of operations

1. Inventory the documents your product emits. Not the ones on your website: the ones your code generates. That is usually where the volume is, and volume is what makes manual remediation impossible.
2. Fix the source markup first. Real headings, real table headers with scope, real lists, meaningful alt, and explicit decorative marking. Nothing downstream can invent structure that was never expressed.
3. Generate tagged output. Confirm your renderer produces a structure tree, and open a sample in a PDF viewer that can show it.
4. Validate automatically, on every render or in CI. Treat a failure the way you would treat a failing test.
5. Review one representative document per template by hand. Reading order and alt-text quality, the two things step 4 will never catch. Templates repeat, so this is a per-template cost, not a per-document one.
6. Keep the evidence. The Act's conformity mechanism expects you to be able to demonstrate how requirements are met, not just assert it. Per-render validation results are the cheapest artifact that does that.

Where this leaves you

The gap is not that WCAG is wrong or that PDF/UA is obscure. It is that most teams do one accessibility project, scope it to the interface, and never learn that the documents their product generates are governed by a different clause and a different technical standard.

If you generate documents at any volume, the cost curve is not subtle. Remediating a PDF after the fact is priced per page, by people. Generating it with the structure already in place is a property of the template, paid once.

PolyDoc's PDF/UA option produces tagged output from your HTML and can run veraPDF as part of the same request, returning a failure instead of a document when the check does not pass. The two thirds above is still two thirds; steps 2 and 5 are still yours. What it removes is the part that should never have been manual. For how that fits alongside PDF/A and what the Accessibility Act does and does not ask of you, see the accessible PDF overview.

Standards references checked 3 August 2026: EN 301 549 v3.2.1, ISO 14289-1:2012, Matterhorn Protocol 1.1. Enforcement practice under the Accessibility Act keeps moving; verify against the primary source before relying on it.