Your PDFs are part of your website’s accessibility
Last updated:
Every organisation that would never ship an inaccessible web page routinely ships inaccessible PDFs: the annual report, the product manual, the application form, the price list. For the visitor who downloads them, there is no difference — a document they cannot read is a service they cannot use. This article treats published PDFs as what they are, part of the website’s accessibility surface, and walks through the six structural signals that decide whether assistive technology can work with a document at all: tagging, language, title, structure and headings, image alt text, and bookmarks. It also draws the line honestly: a light structural check is a smoke test, not PDF/UA validation, and knowing when you need the full thing is part of doing this properly.
The documents are part of the site
Accessibility work tends to stop at the edge of the HTML. The site gets an audit, the templates get fixed, the contrast gets checked — and then the “documents” section quietly keeps serving scanned forms, untagged exports and manuals whose entire text is one embedded image. Yet from the user’s side of the screen, the PDF is the website: it is where the pension form lives, where the safety instructions live, where the detailed pricing lives. A screen-reader user who sails through your accessible pages and hits an untagged 90-page report has not experienced an accessible service; they have experienced an accessible lobby and a locked room.
The good news is that document accessibility fails in predictable, checkable ways. Unlike the judgement calls in web accessibility — is this interaction pattern understandable, is that focus order logical — the most common PDF failures are structural facts that a machine can verify: the tags are there or they are not, the language is declared or it is not. That is exactly what this site’s PDF Accessibility Checker reads, locally in the browser, and it pairs naturally with the Website Health Check: one covers the pages, the other covers the files the pages hand out.
The European Accessibility Act changed the stakes
Since 28 June 2025, the European Accessibility Act has applied to a wide range of products and services offered to consumers in the EU — including e-commerce, banking, e-books, ticketing and much of everyday digital business. Its requirements are commonly met by conforming to the harmonised standard EN 301 549, which in turn points at WCAG — and WCAG applies to non-web documents as well as web pages. In plain terms: for covered services, an inaccessible PDF that a customer needs is no longer just a quality problem or an ethical one; it is a compliance matter, with market-surveillance authorities able to act on it.
Two limits are worth stating plainly, because accessibility law is often both over- and under-claimed. The Act does not cover every organisation or every document — there are exemptions (microenterprises providing services, for example) and transitional arrangements, and the details differ by member state. And no automated check, including the one on this site, establishes legal compliance; compliance is a property of the whole service as experienced by users, assessed properly. What the Act changes for most teams is simpler: documents are now unambiguously in scope of the accessibility conversation, so “we will fix the PDFs later” has stopped being a safe sentence.
The six checks, one by one
1. Tagged PDF. Tagging is the hidden structure tree that marks headings, paragraphs, lists, figures and table cells, and records the reading order. It is the foundation: without tags, a screen reader gets a content stream in storage order, which for multi-column layouts and exported reports can be close to word salad. What the check cannot tell you: whether the tags are correct — a document can be tagged and still have headings marked as paragraphs. Tagged is necessary, not sufficient.
2. Document language. The catalog’s /Lang entry tells speech synthesis which language to pronounce. Without it, an English screen reader will cheerfully read a German report with English phonetics, which ranges from comical to incomprehensible. The check is binary — a language is declared or it is not — and it cannot tell you whether the declared language is the right one, or whether passages in other languages are marked individually, as good practice requires.
3. Document title. The title in the document properties (or XMP metadata) is what assistive technology announces first, what a browser tab shows, and what a downloads folder should display — instead of “export_final_v3.pdf”. The related viewer preference, DisplayDocTitle, decides whether PDF readers show that title rather than the file name; the checker reports it separately because a present-but-hidden title is a half-finished fix. What the check cannot judge is title quality: “Report” passes, and helps nobody.
4. Structure tree and headings. A structure tree with real heading elements (H, H1–H6) is how non-visual readers skim: heading navigation is the single most-used strategy for finding information in long documents. The check counts heading elements when the tree is recoverable. It cannot tell you whether the heading levels are in a sane order or whether the headings describe their sections — a tree full of “Untitled” headings passes the count and fails the reader.
5. Image alt text. The checker counts image XObjects in the pages against /Figure structure elements carrying a non-empty /Alt, and labels the result an approximation — because one figure can wrap several images, decorative images rightly carry empty alt, and the mapping between drawn images and structure elements is not one-to-one. Treat it as a coverage smoke alarm, not an audit. And it can never judge the alt text itself: “image123.jpg” is non-empty alt text, and it is worthless.
6. Bookmarks. The document outline is the handrail for long documents: a 200-page manual with bookmarks is navigable, without them it is a scroll. The check reads the outline’s declared count. It cannot tell you whether the bookmarks are labelled usefully or point at the right pages — only that the navigation exists. For short documents this matters least of the six; for reports and manuals it is the difference between a reference and a haystack.
A smoke test is not PDF/UA validation
PDF/UA (ISO 14289) is the full standard for accessible PDF: tagged structure, correct reading order, table headers, link annotations, form-field labels, contrast, and more, verified by validators and by human testing. The free, open-source veraPDF is the reference validator — a desktop tool that checks a file against the PDF/UA machine-checkable rules in depth. A six-signal browser check does not compete with that, and this article’s tool says so on its own page: it is the smoke test you run across a whole documents library in an afternoon, to find which files are missing the basics, not the certification you cite.
You need the full thing when the document is essential (a form a customer must complete, statutory information, an exam paper), when a procurement or compliance process asks for evidence, when the document is long and structural (manuals, annual reports), or whenever the light check’s unknowns and approximations are not good enough for the decision you are making. Professional remediation — fixing reading order, tables and forms in a dedicated tool, then validating — is a real discipline with real cost, which is exactly why the cheap smoke test earns its place first: it tells you where that money actually needs to go.
A pragmatic order of fixes
Fix in this order, at the source wherever possible. First, the pipeline: turn on tagged-PDF export in Word, InDesign or your reporting tool, and set document language and title in the template’s properties — most libraries of PDFs fail the same three checks because they share one broken template, so one template fix re-publishes clean files forever. Second, headings: use real heading styles in the source and regenerate bookmarks from them; this fixes checks 4 and 6 together. Third, images: write alt text in the source for informative images, and mark decorative ones decorative — do not batch-fill alt with file names. Fourth, the backlog: triage the existing library by downloads and importance, smoke-test everything with the checker, remediate the essential documents properly, and replace or withdraw the long tail you no longer stand behind.
Finally, keep documents inside the routine that keeps the pages honest. When a new PDF is published, run the same six checks before it goes live — it takes under a minute — and re-run the Website Health Check on the page that links it. Accessibility regressions rarely arrive as dramatic redesigns; they arrive as one untagged export, uploaded on a Friday, that nobody checked. Documents are part of the site. Check them like it.