How to Make a PDF Accessible (WCAG 2.2 and PDF/UA)

Most organisations fix their website and forget the documents on it. The policy PDF, the price list, the application form, the annual report: to a screen reader, an ordinary PDF is closer to a photograph of a document than to a document. The good news is that the fixes are well defined and mostly one-time. This guide covers what makes a PDF accessible under WCAG 2.2 and PDF/UA, in the order things usually break.

Why PDFs fail

A PDF stores instructions for painting marks on a page. Nothing in that description tells assistive technology that one line is a heading, that a block of text is a table, or which column to read first. That meaning comes from a separate layer called the structure tree, built out of tags. A PDF without tags is untagged, and an untagged PDF is effectively unreadable by a screen reader no matter how clear it looks on screen.

This matters legally as much as practically. Documents published by a covered organisation sit inside the same scope as its web pages, whether that scope comes from the ADA, Section 508, or the European Accessibility Act. A perfectly accessible website that serves inaccessible PDFs has moved the barrier, not removed it.

The checklist

Roughly in the order that real documents fail. Each item names the WCAG 2.2 success criterion it maps to, because that is the language an auditor or a legal request will use.

• Tags exist at all (1.3.1 Info and Relationships) - the document has a structure tree, and it uses standard tag types rather than custom ones invented by the exporting tool. Custom tags that are not mapped back to standard roles are treated as meaningless.
• Reading order is correct (1.3.2 Meaningful Sequence) - the order of the structure tree, not the visual layout, is what gets read aloud. Multi-column layouts, pull quotes and sidebars are where this goes wrong most often.
• Headings are real headings (2.4.6 Headings and Labels) - tagged H1, H2, H3 in a sensible nesting order, not just larger bold text. This is how most screen reader users navigate a long document.
• Images have alt text (1.1.1 Non-text Content) - every meaningful image, chart and logo carries a description. Decorative artwork is marked as an artifact so it is skipped rather than announced.
• Nothing meaningful is hidden in an artifact - the reverse failure, and a common one. Real content marked as decorative disappears entirely from assistive technology while still being visible on the page.
• Tables have header cells (1.3.1) - header rows and columns are tagged as TH with the right scope, so a screen reader can say which row and column a value belongs to. A table tagged as plain paragraphs is a wall of disconnected numbers.
• Links describe where they go (2.4.4 Link Purpose) - the link text says “2026 fee schedule”, not “click here” or a bare URL. Link annotations also need their own alternate description.
• Form fields are labelled (3.3.2 Labels or Instructions) - every field has a tooltip or label that names it, and the tab order follows the visual order.
• The document language is set (3.1.1 Language of Page) - without it, a screen reader may read English text with a French voice, or the reverse.
• The document has a title (2.4.2 Page Titled) - a real title in the document properties, set to display instead of the file name. “Microsoft Word - final_v3_FINAL.docx” is what users hear otherwise.
• Text contrast passes (1.4.3 Contrast Minimum) - 4.5:1 for body text, 3:1 for large text. Brand greys on white and white text over photographs are the usual culprits.

Scanned documents are a different problem

If your PDF came from a scanner or a photocopier, every page is a single image. There is no text to tag, so none of the checklist above can be applied until the file has been through optical character recognition. Run OCR first, proofread the result, then tag the document. Skipping straight to a tagging tool on a scanned file produces a document that reports structure it does not really have.

PDF/UA and how it relates to WCAG

WCAG was written for web content, so it does not say anything about PDF-specific machinery like the structure tree or artifacts. PDF/UA is the standard that fills that gap: it is the technical specification for what an accessible PDF file must contain.

• PDF/UA-1 (ISO 14289-1) is the established version, built on PDF 1.7. It is what almost every procurement rule and accessibility policy means today when it says “PDF/UA”.
• PDF/UA-2 (ISO 14289-2) is the newer version, built on PDF 2.0. It adds support for newer structure features and tightens several requirements.

The two standards answer different questions and you generally want both. WCAG 2.2 Level AA is the target the law points at; PDF/UA is how you prove the file is built correctly. A document can pass a PDF/UA structural check and still fail WCAG, because no automated standard can tell whether alt text is accurate or whether the reading order actually makes sense.

How to fix a PDF

Fixing the source document is almost always cheaper than repairing the PDF afterwards, so start upstream wherever you still can.

• Word, Google Docs, InDesign - use real heading styles, add alt text to images, mark table header rows, then export with the tagged or accessible option enabled. Printing to PDF discards all of it, so use Save As or Export instead.
• Acrobat Pro - the Accessibility tools give you the reading order panel and the tag tree for repairing an existing file. This is the most capable option and the only practical one for documents whose source is lost.
• LibreOffice - a free path that exports tagged PDFs and handles headings, alt text and language correctly.

How to verify, and why checkers disagree

Once a document is fixed, validate it rather than trusting the export. Here is the part worth knowing before you believe any tool, including ours.

Validators work by walking the structure of a file and reporting rule violations. If the file cannot be parsed, there is no structure to walk, so there are no violations to report. The honest answer is “this could not be analysed”, but a naive checker reports zero failures, which then gets rendered as a perfect score. Two cases trigger this regularly:

• A file that is not really a PDF - a corrupt upload, or something renamed to .pdf. Nothing parses, nothing fails, and it scores full marks.
• A password-protected PDF - the content is encrypted, so the validator reads nothing and reports nothing.

Both produce a confident pass on a document that was never examined, which is worse than no result at all: you stop looking. We reject both cases explicitly and return a clear error instead of a score, and our automated contrast check renders each page and samples the actual pixels rather than guessing at colours from drawing commands. Our methodology covers where the automated line sits and what still needs a human.

Where to start

Find your most-downloaded documents, not your newest ones. A form that thousands of people need matters more than last quarter’s report. Check those first, fix the structural failures before the cosmetic ones, and fix the template they came from so the next version starts accessible. You can check a PDF against WCAG 2.2 and both PDF/UA versions on our home page, and the WCAG 2.2 checklist covers the web side of the same standard.