PDF/UA Explained: The Standard Behind Accessible PDFs

'Accessible PDF' is a phrase that turns up in procurement documents, vendor contracts and accessibility statements, usually without anyone pausing to define it. Behind the phrase sits a specific, published standard: PDF/UA, the international standard for universally accessible PDF. Knowing what that standard actually requires, rather than treating accessibility as a vague aspiration, is what separates a document that survives an audit from one that merely looks tidy on screen.

This article explains what PDF/UA is, how it relates to the more familiar WCAG, and how conformance to it is defined and tested. It is deliberately about the standard itself rather than the hands-on repair work; readers who want the step-by-step remediation tasks of tagging, reading order, tables and the rest will find those in our companion guide at /blog/accessible-pdf-remediation-guide/. The aim here is to give managers and content owners a clear mental model of the rules their documents are actually being measured against.

PDF/UA, where the 'UA' stands for Universal Accessibility, is the ISO standard that defines how a PDF must be built so that assistive technology can read it reliably. Formally it is ISO 14289, first published as ISO 14289-1 in 2012 and revised in 2014 [HV: verify before publish — ISO 14289-1 publication year 2012 and 2014 revision]. It does not replace the base PDF specification; it constrains it, specifying which features an accessible file must use and which it must avoid. The foundation it builds on is Tagged PDF, the structural layer defined in the core PDF specification (ISO 32000) that most ordinary PDFs either omit or implement badly.

The distinction worth holding onto is that PDF/UA governs construction, not appearance. A file can look identical on screen whether or not it conforms; the difference lives in the invisible structure underneath. Where a sighted reader recognizes a heading because it is large and bold, a conforming file also carries a heading tag that announces 'this is a heading' to a screen reader. PDF/UA is the rulebook for that parallel, machine-readable version of the document.

Most organizations meet accessibility first through WCAG, the Web Content Accessibility Guidelines, and reasonably ask how a separate PDF standard fits alongside it. The cleanest way to think about it is this: WCAG is technology-neutral and describes outcomes, requiring that content be perceivable, operable, understandable and robust, without saying how any particular format should achieve them. PDF/UA is format-specific and prescriptive, translating those outcomes into concrete rules for how PDF objects, tags and metadata must be arranged. They are complementary layers, not competing standards.

In practice the two meet at the document. The W3C publishes a set of PDF techniques that show how specific WCAG success criteria can be satisfied inside a PDF, and a file built to PDF/UA will generally satisfy the document-level expectations WCAG sets out. The relationship is not perfectly one-to-one: WCAG still governs how a document behaves once it is open in a browser or viewer, including contrast, link text and the experience of interactive forms, so a thorough conformance claim usually references both. Our earlier post at /blog/wcag-2-2-document-compliance/ covers how WCAG 2.2 and the European Accessibility Act push these obligations into everyday documents.

Underneath a PDF/UA file is a structure tree: an ordered hierarchy of tags that mirrors the document's logical organization. This tree is what assistive technology actually traverses. Headings nest in sensible levels, lists are marked as lists rather than as indented paragraphs, tables expose their header and data cells, and every figure either carries alternative text or is declared decorative. Content that exists only for visual effect, such as running heads, page numbers and background rules, is tagged as an artifact so it never reaches the reading order.

Alongside the tags sit document-level requirements: a declared language so a screen reader pronounces words correctly, a title shown in place of the filename, and embedded fonts with proper character mappings so that copied or spoken text is the real text rather than gibberish. A conforming file also carries a metadata flag stating that it claims PDF/UA conformance, which is how downstream tools and auditors recognize the intent.

One nuance the standard makes explicit is the line between presence and quality. PDF/UA can require that every image has alternative text; it cannot require that the text is useful. Whether a chart's description conveys the trend the author intended, or merely says 'image', is an editorial judgment no file-level rule can enforce. That gap is exactly why conformance testing combines automated checks with human review, a point the next sections return to.

A feature of PDF/UA that surprises people new to it is that the standard does not only describe files. It also sets expectations for the software that displays them and for the assistive technologies that read them. Accessibility is treated as a chain: a perfectly tagged document still fails the user if the viewer ignores the tags or the screen reader cannot interpret them. The standard's scope therefore extends to conforming readers and processors, not just to the document on disk.

For most organizations the practical obligation is narrower, since their job is to produce conforming files, but the chain explains why testing has to happen in real software rather than on paper. A document that validates against the rules but is only ever opened in a viewer that strips its structure has not delivered an accessible experience. It is also why conformance is best described as something supported by an ecosystem rather than a property a file carries in isolation.

Because 'does this file conform to PDF/UA?' is too broad a question to answer by inspection, the PDF Association maintains the Matterhorn Protocol, a structured framework that turns the standard into a checklist of discrete, testable conditions. It organizes the requirements into a set of checkpoints and failure conditions [HV: verify before publish — Matterhorn Protocol 1.02 has 31 checkpoints and 136 failure conditions] that an auditor or a tool can work through methodically rather than judging the file holistically.

Crucially, the protocol distinguishes failures a machine can detect from those that need a human. A missing language declaration or an untagged image is machine-checkable; whether the reading order makes narrative sense, or whether alternative text is meaningful, requires a person. Free tools such as PAC, the PDF Accessibility Checker, automate the machine-testable portion and preview the structure as assistive technology would encounter it, but they can only ever clear the mechanical half of the standard.

The implication for buyers is to treat a clean automated report as a necessary entry condition, not as proof of accessibility. A conformance claim that rests solely on a tool's green checkmark is incomplete by the standard's own design. Genuine assurance pairs the automated pass with a human review and, ideally, a few minutes of listening to the document in a screen reader, the discipline our /blog/accessible-pdf-remediation-guide/ sets out in detail.

PDF/UA has moved from a specialist concern to standard procurement language because regulators and buyers needed a precise, citable benchmark for documents. Accessibility frameworks reference it: in the United States, Section 508 procurement expectations point to recognized accessibility standards for electronic documents, and in Europe the harmonized standard behind the European Accessibility Act addresses PDF accessibility through the same lens. When a tender or a vendor contract asks for 'accessible PDFs', PDF/UA is increasingly the specific thing it means.

This is where a standard stops being academic. Conformance claims now travel with documents in the form of accessibility statements and, for software and document deliverables, VPAT and ACR documentation that records how a product measures against the relevant criteria. Vendors are being asked to warrant accessibility rather than merely describe it, which makes a defensible, tested conformance position a commercial asset rather than a compliance afterthought.

Our technology service line handles document remediation to PDF/UA alongside WCAG and Section 508 audits, delivered with our parent company Squash Apps; the details are on /technology/. Whether that work is done in-house or with a partner, understanding the standard pays off the same way: it lets you write sharper requirements, judge a vendor's conformance claim on its merits, and tell the difference between a document that passes a checker and one that genuinely works for its readers.