Skip to content
wcagc
←Back to blog
PDF/UAWCAGEN 301 549Section 508how-to

How to make a PDF accessible (PDF/UA)

The tags an accessible PDF needs, how to export them from the source document, and how to check the file before you publish it.

P

Pavel Charkasau

To make a PDF accessible you give it a tag tree that assistive technology can read, and the cheapest place to do that is in the source document, before the PDF exists. A file that holds up needs every piece of real content inside the structure tree, headings tagged as headings in the order they are read, figures carrying an /Alt entry, tables with real header cells, a title in the document metadata, and a declared language. That list comes from two places: PDF/UA (ISO 14289-1:2014), the file-format standard for accessible PDF, and WCAG, which reaches downloadable documents through EN 301 549 clause 10 and through Section 508's E205.4 (Access Board). So the working order is: fix the Word or InDesign file, export with tagging switched on, repair what the export missed in Acrobat Pro, then validate. Validation is where expectations need managing. Of the 136 documented ways to fail PDF/UA-1, 87 can be settled by software and 47 need a person to look (PDF Association).

What counts as an accessible PDF?

Two standards apply at once, and they answer different questions.

WCAG asks whether the content works for the reader: alt text, contrast, reading order, form labels. PDF/UA asks whether the file carries the machinery that makes any of that reachable: the tag tree, artifacts, the /Lang and title entries. You can write perfect alt text into an untagged PDF and no screen reader will find it. You can also produce a technically valid PDF/UA file whose alt text says Picture 3.

EN 301 549 is explicit about which files are in scope. Clause 10 covers "documents that are not web pages", documents not embedded in web pages, and "documents that are provided with web pages but are neither embedded nor rendered together with the web page from which they are provided", which the standard then glosses as downloadable documents (ETSI EN 301 549 V3.2.1). Clause 10 note 7 adds a detail teams miss: the requirements still apply to documents protected by digital signatures, encryption, password protection, or watermarks. A locked-down bank statement is in scope.

Four requirements drop away for single documents, and EN 301 549 marks them "Void": 10.2.4.1 Bypass Blocks, 10.2.4.5 Multiple Ways, 10.3.2.3 Consistent Navigation, and 10.3.2.4 Consistent Identification. The standard's note explains why — those are properties of sets of pages, not of one file. US Section 508 carves out the same four (Access Board). Everything else in WCAG 2.1 AA still has to be satisfied.

The bridge between web-shaped criteria and documents is WCAG2ICT, which the W3C published as a Group Note on 11 December 2025 covering WCAG 2.0, 2.1 and 2.2 for non-web content (W3C). EN 301 549 clause 10 says outright that its criteria are intended to harmonise with the WCAG2ICT work. If you are arguing with a supplier about how a success criterion applies to a PDF, WCAG2ICT is the document to open.

Which tags does the file actually need?

W3C publishes PDF-specific techniques for WCAG, PDF1 through PDF23, and they are the most practical checklist available because each one names the PDF structure involved rather than the intent (W3C). The ones that carry most of the weight:

What the reader needsWhat goes in the fileTechnique
Images described/Alt entry on the figurePDF1
Decoration skippedcontent marked as /ArtifactPDF4
Sections navigableH1–H6 heading tags in hierarchyPDF9
Tables read correctlyTable, TR, TH with scope, TDPDF6
Lists announced as listsL, LI, Lbl, LBody tagsPDF21
Correct pronunciation/Lang in the document catalogPDF16
A window title that means somethingTitle in the document info dictionaryPDF18
Links that make senseLink annotation plus /Link structure elementPDF11
Forms that can be completedfield labels and name/role/valuePDF10, PDF12
Scanned pages readable at allOCR to produce real textPDF7

Reading order gets its own technique, PDF3, and it is the one that most often looks fine and is not. The tag tree order, not the visual position on the page, decides what a screen reader says next. A two-column layout exported carelessly reads left column, right column, left column, and every word is present, which is exactly why nobody notices.

How do I produce a tagged PDF from Word or InDesign?

Do the work upstream. Retagging a finished PDF in Acrobat is slow, and it has to be redone every time someone edits the source and re-exports.

In Word, Microsoft's documented path is: run the Accessibility Checker on the document first, then File → Save As (or Save a Copy), choose PDF, open Options, and confirm Document structure tags for accessibility is ticked (Microsoft). Microsoft's own framing is that the Checker is the fastest way to get this right, because Microsoft 365 uses what the Checker knows about your document to build the tags. That means the tags are only as good as your styles. Bold 16pt text is not a heading; a paragraph styled Heading 2 is. Tables built with real header rows export with TH cells, tables built by nudging tabs do not.

In InDesign the equivalent discipline is paragraph styles mapped to export tags, alt text set on placed images, and the Articles panel used to fix the order before export rather than after.

Then open the result in Acrobat Pro and repair what survived badly. Usually that is a short list: a few figures that need /Alt, decorative rules to mark as artifacts, a table or two, and the document title. If the list is long, the source file is the problem and you should go back to it.

How do I check whether a PDF passes?

Run a validator, then read the file with your eyes.

veraPDF is the open-source option and the one I trust for the machine half. It validates PDF/UA parts 1 and 2 alongside PDF/A, it is built by the Open Preservation Foundation with the PDF Association, and it came out of the European Commission's PREFORMA project. Our own PDF accessibility checker runs veraPDF against the PDF/UA-1 profile and reports the failed clauses, so you get the same verdict without installing anything. PAC is the other widely used desktop checker.

Now the honest part. The PDF Association's Matterhorn Protocol is the catalogue of every way a file can fail PDF/UA-1: 31 checkpoints, 136 failure conditions. Of those, 87 can be determined by software alone and 47 usually require human judgement (PDF Association). So a clean validator report covers roughly two thirds of the ways this goes wrong. It is the same split we publish for web scanning, where automated coverage lands somewhere between 30% and 57% depending on how you count (Deque), and it exists for the same reason: software can see that a figure has an /Alt entry, not whether the entry describes the figure.

The 47 you have to check yourself are the interesting ones. Is the reading order actually the reading order. Do the heading levels reflect the document's real structure or the designer's font sizes. Is the alt text useful. Is that background image genuinely decorative. Budget twenty minutes with a screen reader per document and you will find them.

My opinion, and I will state it plainly: most organisations should publish fewer PDFs. The US General Services Administration's guidance is blunt about it — "Federal policy requires agencies to prioritize HTML and use PDFs only when necessary" (Section508.gov). An HTML page reflows on a phone and gets checked by your own tooling on every deploy. Remediating a 90-page PDF that should have been a web page is work you chose.

Does the law require accessible PDFs?

In the EU, the European Accessibility Act reaches them through the service requirements rather than by naming PDF. Annex I, Section III requires making information content "available in text formats that can be used to generate alternative assistive formats", supplementing non-textual content with an alternative presentation, and providing "electronic information needed in the provision of the service in a consistent and adequate way by making it perceivable, operable, understandable and robust" (EUR-Lex). A contract or an account statement delivered as a PDF is electronic information needed in the provision of the service. The technical route to satisfying it is EN 301 549 clause 10.

In the US, Section 508 requires electronic content to conform to WCAG 2.0 Level A and AA under E205.4, with the four non-web exceptions noted above (Access Board).

Neither text says "ISO 14289". PDF/UA is the practical means, not the legal instrument: it specifies the file-format mechanics that WCAG assumes and does not describe. Meeting PDF/UA gets you most of the way to a clause 10 claim; it does not by itself constitute one.

Frequently asked questions

What is PDF/UA in one sentence?

PDF/UA is the ISO standard for accessible PDF files (ISO 14289-1:2014 for PDF 1.7, ISO 14289-2:2024 for PDF 2.0), and it specifies how a document must be tagged so assistive technology can read it (ISO).

Is a tagged PDF the same as an accessible PDF?

No. Tagging is necessary and not sufficient. A file can be fully tagged and still fail, because the tags are wrong: headings applied by font size, alt text reading image1.png, a table whose header row is tagged as ordinary cells. Software checks that tags exist; a person checks that they are right.

Can a scanner tell me my PDF is compliant?

It can tell you the file passes the machine-checkable part. The Matterhorn Protocol splits PDF/UA-1's 136 failure conditions into 87 that software can determine and 47 that need human judgement (PDF Association). Treat a clean report as a floor.

Do accessibility rules apply to password-protected PDFs?

Yes. EN 301 549 clause 10 note 7 states the requirements apply to documents protected by digital signatures, encryption, password protection, and watermarks (ETSI).

Which WCAG criteria do not apply to a single PDF?

Four, and EN 301 549 marks them Void in clause 10: Bypass Blocks, Multiple Ways, Consistent Navigation, and Consistent Identification. They describe relationships between pages, so a single document cannot meet or fail them (ETSI).

Check a PDF before you publish it

Upload a file to our PDF accessibility checker and you get the veraPDF verdict against PDF/UA-1 with the failed clauses named, which handles the 87 conditions a machine can settle. Then do the twenty-minute pass yourself on reading order and alt text. If the documents live on a site you also need to keep conformant, run a free scan of the pages that link to them, because a perfectly tagged PDF behind an unlabelled download link is still unreachable.

Pavel Charkasau, founder, wcagc.com. Last updated 18 August 2026.

Sources