What is PDF/UA? The ISO standard for accessible PDFs
PDF/UA stands for “PDF/Universal Accessibility” and is published as ISO 14289. It sets out how a PDF has to be built internally so that screen readers, magnifiers and other assistive technologies can read it reliably. Layout and colour are largely outside its remit.
Last updated:
A profile, not a new format
A PDF/UA file is an ordinary PDF and opens in any reader. The standard simply prescribes which parts of the PDF format must be used, and how. The difference from any other PDF is on the inside: content carries semantic markup, the metadata is complete, and fonts are set up so that every character can be extracted unambiguously.
It is aimed at people who create PDFs, at software that produces them (converters, prepress tools, document management systems) and at software that processes or reads them aloud, meaning readers, screen readers and validators.
PDF/UA-1 and PDF/UA-2
ISO 14289 currently has two parts. PDF/UA-1 (ISO 14289-1) is based on PDF 1.7 (ISO 32000-1). The first edition appeared in 2012; the current one is the revised edition of 2014. Almost every validator and export feature still targets this part.
PDF/UA-2 (ISO 14289-2:2024) carries the requirements over to PDF 2.0 (ISO 32000-2). That brings in the PDF 2.0 structure namespace, with elements such as Title, Aside or FENote for footnotes and endnotes. Formulas can be embedded as MathML.
Also in 2024, the PDF Association published Well-Tagged PDF (WTPDF) 1.0. It has two conformance levels, one for accessibility and one for content reuse. According to the PDF Association, the accessibility level has the same requirements as PDF/UA-2, and WTPDF likewise requires PDF 2.0.
For most document workflows, PDF/UA-1 is still the safe choice. Authoring tools, validators and screen readers handle it best. Moving to PDF/UA-2 makes sense once your tool chain produces clean PDF 2.0, or if you need to output mathematical content in structured form.
Where documents fail in practice
The standard is made up of many detailed rules. Whether a document passes usually comes down to the ones below.
| Requirement | Technical implementation in the PDF | Typical error |
|---|---|---|
| Tagged content | Structure tree with semantic tags such as H1, P, L, Table, Figure; file marked as tagged (MarkInfo) | No structure tree, or only generic tags without meaning |
| Artifacts | Running headers and footers, page numbers and decorative elements are marked as artifacts | Content that is neither tagged nor marked as an artifact |
| Document title | Title in the XMP metadata (dc:title) and shown instead of the file name (DisplayDocTitle) | Missing title, or the file name shown in the title bar |
| Language | Default language in the document catalog (/Lang), passages in other languages with their own Lang entry | No language set, so the screen reader uses the wrong pronunciation |
| Fonts and Unicode | All fonts embedded, every character mapped unambiguously to Unicode (for example via a ToUnicode CMap) | Non-embedded fonts, garbled characters when reading aloud or copying |
| Alternative text | Alt entry for Figure, formulas and other non-text content | Figures without alternative text |
| Tables | Table, TR, TH, TD; header cells associated via Scope or Headers | Tables without header cells, or tagged as running text |
| Annotations | Links and form fields are tied into the structure via Link and Form elements; pages with annotations use /Tabs /S | Link annotations without a structure element or description |
| PDF/UA identifier | pdfuaid:part entry in the XMP metadata stream | Identifier missing although the file would otherwise conform |
The last row is often misread. With pdfuaid:part the creator claims that the file is meant to conform. The entry proves nothing; only validation shows whether the document actually does.
The Matterhorn Protocol
So that PDF/UA-1 can be tested consistently, the PDF Association publishes the Matterhorn Protocol, currently version 1.1 from 2021. It breaks the standard down into 31 checkpoints with 136 failure conditions in total. Each failure condition describes a specific violation, such as “figure without alternative text” or “content neither tagged nor marked as an artifact”.
Some of these conditions are machine-checkable. Software can tell unambiguously whether a title is set, whether all fonts are embedded or whether a Figure tag lacks alternative text. The others need judgement. Does the heading hierarchy reflect the content? Is text that looks like a list actually tagged as L? Does the alternative text describe the image usefully? A person has to decide.
A clean automated report therefore only means that the machine-checkable conditions are met. It does not establish PDF/UA conformance.
PAC and veraPDF
PAC (PDF Accessibility Checker) comes from the Swiss foundation Access for All, runs on Windows and is free. It checks against PDF/UA-1 and the Matterhorn Protocol. Extra views such as the structure tree preview are useful during manual review.
veraPDF is open source and was originally built as a PDF/A validator. It also checks the machine-checkable PDF/UA rules and, in current versions, supports PDF/UA-2 and WTPDF as well as PDF/UA-1. It is well suited to automated checks in document workflows.
Neither tool’s messages are always self-explanatory. We cover the most common ones in Common PAC and veraPDF errors. If you only want to see quickly whether tags, title, language, fonts and links are present, you can check a PDF in your browser with the EasyPDFUA PDF/UA checker.
PDF/UA is not PDF/A
PDF/A (ISO 19005) is meant for long-term archiving. A PDF/A document should look the same in several decades as it does today, which is why fonts are embedded and external dependencies are ruled out. Accessibility is not one of its aims. Only the PDF/A-1a, PDF/A-2a and PDF/A-3a levels require a tag structure at all, and even they do not impose PDF/UA’s detailed rules.
The two are compatible. A document can meet PDF/A and PDF/UA at once and then carries both identifiers in its metadata. Public bodies and banks that must archive documents and publish them accessibly have good reason to want both.
How it relates to WCAG and the law
PDF/UA governs technical structure. Colour contrast, meaningful link text and the quality of alternative text are outside its scope or only touched on. Those are matters for WCAG, which applies to PDF documents through the European standard EN 301 549. Our PDF/UA vs. WCAG comparison shows how the two interlock, and WCAG 2.2 for PDF documents lists the success criteria that apply to PDFs.
The European Accessibility Act and national laws do not name PDF/UA. It is, however, the recognised technical route to building PDFs that can meet the requirements of EN 301 549.
Where to start
PDF/UA is least work when the structure is already right in the source file. If you use styles for headings, lists and tables in Word or InDesign, add alternative text there and export with tagging enabled, most of the job is done. After that comes a technical check with PAC, veraPDF or an online checker, then a manual look at reading order, headings, tables and alternative text. Our accessible PDF checklist is made for that step.
For legacy files without a source, retroactive tagging is the remaining option. EasyPDFUA conservatively adds basic tags, title, language, links and repairable font mappings. It does not reconstruct headings, lists, tables or figures automatically. That part stays manual.
Frequently asked questions
Is PDF/UA legally required?
Not by name. EU directives and national laws such as Austria's BaFG or Germany's BFSG require accessible content. In practice that is measured against EN 301 549 and therefore WCAG, and PDF/UA is the recognised technical way to build PDFs that meet it.
What is the difference between PDF/UA-1 and PDF/UA-2?
PDF/UA-1 (ISO 14289-1:2014) is based on PDF 1.7 and has the broadest tool support. PDF/UA-2 (ISO 14289-2:2024) requires PDF 2.0, uses its extended structure elements and allows MathML for formulas, among other things.
Does the PDF/UA identifier in the metadata make a document conformant?
No. The pdfuaid:part entry is only the creator's claim that the file is meant to conform. Whether it does is shown by automated and manual validation.
Is a clean PAC report enough for PDF/UA?
No. PAC and veraPDF cover the machine-checkable failure conditions of the Matterhorn Protocol. Whether alternative text is meaningful, the heading hierarchy is correct and the reading order makes sense has to be judged by a person.
Can a PDF be PDF/A and PDF/UA at the same time?
Yes. PDF/A is about archiving, PDF/UA about accessibility, and one file can meet both. It then carries both identifiers in its metadata.