If you work with digital documents, you have probably heard the term PDF/UA. It stands for PDF/Universal Accessibility and is the international standard published as ISO 14289. Its purpose is simple: to make PDF files accessible to people who use assistive technologies such as screen readers, magnifiers, Braille displays, and switch devices.
PDF/UA is not a separate file format. It is a set of rules that tells authors and software developers how to create PDFs so that everyone can read and navigate them. A PDF/UA-conformant document keeps its semantic structure intact, which means headings, lists, tables, links, and form fields are not just visual objects but meaningful pieces of information.
What PDF/UA Covers
The standard addresses many parts of a PDF file. Understanding these areas helps you see why some documents fail accessibility checks while others pass.
Tagged content. PDF/UA requires that content be tagged. Tags describe the role of each element, such as a paragraph, heading, figure, or table cell. Without tags, a screen reader sees only a stream of text and cannot tell where a section begins or ends.
Logical reading order. A document must be readable from top to bottom and left to right in a logical sequence. Multi-column layouts, sidebars, and floating text boxes can confuse assistive technology if the reading order is wrong.
Alternative text. Images, charts, and diagrams need concise text descriptions. Decorative images should be marked as artifacts so screen readers skip them.
Fonts and characters. Text must be embedded or mapped correctly. If a PDF contains only images of text, screen readers cannot extract any words.
Navigation and links. Bookmarks, a table of contents, and clickable links make long documents easier to explore. PDF/UA also expects link text to describe its destination rather than saying "click here."
Forms. Interactive form fields need labels, tooltips, and a logical tab order. Users should be able to complete and submit forms without a mouse.
Metadata. The document should declare its title, language, and author. This metadata helps software identify the document and present it correctly.
How PDF/UA Relates to WCAG
WCAG, the Web Content Accessibility Guidelines, is the best-known standard for web accessibility. PDF/UA and WCAG share the same goal but target different technologies. WCAG focuses on HTML, CSS, and JavaScript, while PDF/UA focuses on the PDF format.
WCAG 2.1 and WCAG 2.2 are organized around four principles: content must be perceivable, operable, understandable, and robust. PDF/UA maps closely to these ideas. For example, a tagged PDF satisfies the need for perceivable structure, and keyboard-accessible forms satisfy the operable principle.
In many regions, public-sector bodies must meet WCAG 2.1 Level AA. Because PDFs are often treated as web content, they must also be accessible. PDF/UA is widely accepted as the way to achieve PDF accessibility in a WCAG-aligned manner.
How to Check PDF/UA Conformance
Checking a PDF for accessibility usually involves two steps: automated scanning and manual review.
Start with an automated checker. These tools quickly find missing tags, empty alternative text, incorrect reading order, and missing metadata. They save time but cannot catch every issue.
After the automated scan, do a manual review. Open the document with a screen reader such as NVDA or JAWS. Listen to how the content flows, test links, try to complete forms with the keyboard, and verify that images are described accurately.
Some checks require human judgment. A tool can tell you whether an image has alt text, but it cannot tell you whether the description is useful.
Tools for Creating and Validating PDF/UA
Several tools can help you produce accessible PDFs. Microsoft Word and Adobe InDesign both support tagged PDF export when you use styles and alt text consistently. LibreOffice also provides accessibility options during PDF export.
For validation, Adobe Acrobat Pro includes an accessibility checker and a Make Accessible wizard. axesWord and axesPDF offer dedicated PDF/UA workflows. VeraPDF is a free, open-source validator that tests against ISO 14289 and reports conformance levels. PAC (PDF Accessibility Checker) is a popular Windows tool that combines automated checks with a screen-reader preview.
For developers, libraries such as iText and PDFBox can create tagged PDFs programmatically. These are useful when documents are generated from templates or databases.
Conclusion
PDF/UA gives organizations a clear path to accessible documents. By combining proper authoring practices with automated and manual testing, you can create PDFs that work for all readers. Whether you publish reports, forms, manuals, or invoices, following ISO 14289 helps you meet legal requirements, improve user experience, and show that accessibility matters to your organization.
Related: Validate against the standard with veraPDF online, or see how to read the validation report.
Sources and references
- ISO 14289-1:2014 — PDF/UA-1 standard
- PDF Association — PDF/UA-1 Reference Suite
- veraPDF — Open-source PDF/UA validator
- W3C — WCAG 2.1
What PDF/UA-1 actually checks — the machine-testable rules
The standard specifies roughly 150 machine-checkable requirements. They cluster into six groups that every validator tests:
- Tag tree completeness. Every content element that conveys meaning must be in the tag tree. A paragraph that appears visually as a paragraph must be tagged as <P>. A heading that looks like a heading must be tagged as <H1>–<H6>. This is the single most common failure category — documents that look fine to the eye but have no tag tree at all.
- Metadata integrity. The document must declare its title (not the filename), its primary language (e.g., en-US), and the boolean flag that marks it as a Tagged PDF. Screen readers use the language declaration to select the correct voice and pronunciation rules.
- Alternative text on figures. Every Figure tag must have either an Alt entry (meaningful description) or be marked as an artifact (decorative-only image). Empty or missing alt text is an automatic failure.
- Reading order consistency. The order of elements in the tag tree must match the visual reading order — top to bottom, left to right. Multi-column layouts must read down each column, not across. Validators compare the tag order against layout coordinates to detect cross-column reading.
- Table and list structure. Table cells must reference their header cells. Lists must be structured as List containers with List Items. Without this, a screen reader cannot announce "table with 4 columns" or "list of 7 items."
- Form field labeling. Every form field needs a Tooltip or linked label. A validator cannot check whether the label is correct, but it can flag the absence of one.
How validation works under the hood
A PDF/UA validator like veraPDF works by extracting the PDF's internal data structures and comparing them against the ISO specification. Think of it as a compiler that checks your document against a type system — it does not read the document visually; it inspects the object graph. For each rule (e.g., "every Figure must have an Alt entry"), the validator finds all Figure objects in the PDF and checks whether each has an Alt key. If one does not, it records a failure with the exact object number and page location. The output is a machine-readable report that you can feed into a remediation workflow. This is fundamentally different from a visual check — a document can look perfect and still fail every structural rule, which is why screen-reader users encounter inaccessible PDFs that sighted reviewers never notice.
Tagged vs untagged: a real example
Take a typical 15-page government report published as a PDF. Visually, it has a title page, numbered headings, body paragraphs, three tables, and six charts. Without tags, a screen reader announces it as: "Page 1. Graphic. Page 2. Graphic. Page 3. Graphic…" — because every page is rendered as an undifferentiated image or text block. With PDF/UA-1 tags, the same document becomes: "Heading level 1: Annual Compliance Report. Heading level 2: Executive Summary. List of 7 items. Table: 4 columns, 12 rows. Figure: Revenue by Quarter — bar chart showing Q3 growth of 18 percent." The difference is not incremental — it is the difference between a document and a locked box. Remediation rebuilds the tag tree, and validation with veraPDF confirms the rebuild was correct.
Common misconceptions
"If my source document is accessible, the PDF will be too." Only partially true. A well-structured Word document exports a reasonably tagged PDF — but embedded fonts, complex tables, and multi-column layouts often introduce gaps that require verification. Always validate after export.
"PDF/UA-1 is the same as WCAG." They overlap but are distinct. PDF/UA-1 is a document-structure standard; WCAG is a content-accessibility standard. A document can pass PDF/UA-1 and still fail WCAG on contrast or link-text quality. See our full comparison.
"Automated tagging is 'close enough.'" For the deterministic 90% of rules — tag tree, metadata, reading order — it is exact and verifiable. For judgment items like alt-text quality, automated tagging flags what needs human review. Our report-reading guide explains which is which.