PDF/UA tags a PDF so screen readers and other assistive technology can read the content in the right order, understand the structure, and describe each meaningful part of the document.
The standard behind it is ISO 14289. It gives PDF files accessibility rules, so headings, paragraphs, lists, tables, images, links, and form fields are not just visible on the page but understandable to tools that read the file for users.
A tagged PDF is the method that makes this possible. The tags create a hidden structure inside the file, while PDF/UA is the standard that tells you whether that structure is good enough for accessibility.
PDF/UA also connects closely with WCAG and accessibility laws. Rules like ADA Title II and procurement standards like EN 301 549 point to digital accessibility requirements, while PDF/UA explains how a PDF can meet those expectations in a practical, file-specific way.
One important testing reference is the Matterhorn Protocol. It defines 31 checkpoints and 136 failure conditions for PDF/UA, but not all of them can be checked by software. Some issues, such as whether alt text actually describes an image correctly, still need a person to judge.
This article explains what PDF/UA is, how tagging makes a PDF accessible, what a PDF/UA file needs, and how it differs from a normal PDF. Then it covers PDF/UA vs WCAG, how to check compliance, whether the law requires it, and how to create a file that passes.
What Is PDF/UA?
PDF/UA is the ISO 14289 standard for PDFs that everyone can read, including people who use screen readers and other assistive technology.
The “UA” means Universal Accessibility. The purpose is to ensure a PDF has sufficient structure for assistive tools to understand the content, navigate it in the correct order, and explain its parts accurately.
PDF/UA also has versions. PDF/UA-1 is ISO 14289-1, and PDF/UA-2 is ISO 14289-2. These versions define the rules a file must follow to claim PDF/UA conformance.
A tagged PDF is the method used to build that accessible structure. Tags mark headings, paragraphs, lists, tables, images, links, and form fields so tools can understand what each part means.
The important difference is that PDF/UA is the rulebook, while a tagged PDF is the method. A file can have tags and still fail PDF/UA if the tags are incomplete, wrong, or not useful for real accessibility.
So PDF/UA is the goal you aim for, not the tags themselves. The tags are only one part of reaching that standard.
How Does a Tagged PDF Make a Document Accessible?
Tags add a hidden outline that gives a PDF a clear reading order and labels its headings, lists, tables, images, and other parts so a screen reader can announce them correctly.
This hidden outline is called the tag tree or structure tree. It tells assistive tools what each piece of content means, not just where it appears visually on the page.
Without tags, a PDF may only show text and images as positioned objects. A screen reader may move through the page in the wrong order, skip important content, or read table cells without explaining how they relate to each other.
With semantic tags, the PDF can identify a heading as a heading, a list as a list, a table as a table, and an image as an image. If the image carries useful information, alt text gives the screen reader a short description to announce. A simple table shows the difference clearly.
| Without Proper Tags | With Proper Tags |
|---|---|
| A table may be read cell by cell with no clear pattern | The table is read row by row with headers connected to the right cells |
| A heading may sound like normal text | The heading is announced as a section heading |
| An image may be skipped or read as a file object | The image is described through alt text |
| A two-column layout may be read in the wrong order | The reading order follows the intended document flow |
A screen reader moves through the tagged structure instead of guessing from the visual layout alone. That is how a tagged PDF turns a page that only looks organized into a document that assistive technology can actually understand.
What Are the Requirements for a PDF/UA File?
A PDF/UA file needs a complete tag tree, a clear reading order, alt text for meaningful images, a declared language, a metadata title, correct Unicode mapping, and embedded fonts.
The tag tree is the main structure inside the file. It should mark headings, paragraphs, lists, tables, links, figures, and form fields so assistive tools can understand what each part of the document means.
Reading order must also be clear. A screen reader should move through the PDF in the same order a person would read it visually, rather than jumping between columns, footers, captions, or side notes in a confusing sequence.
Images that carry meaning need alt text. Decorative images can be marked as artifacts, but charts, diagrams, screenshots, icons, and important photos need useful descriptions so the information is not lost.
Two small details often fail first in checkers: the file has no title in the document details, or the document language is not set. A valid PDF/UA file should include a proper metadata title and a declared language such as English, Spanish, or another correct language for the content.
Fonts must be embedded, and text must map correctly to Unicode. That helps assistive technology copy, search, pronounce, and announce characters correctly instead of reading broken symbols or empty text.
Security settings also matter. A PDF can use passwords or restrictions only if they do not block screen readers, text extraction for accessibility, or other assistive tools from accessing the content.
How Does PDF/UA Differ From a Standard PDF?
A standard PDF can look like normal text on the page but still act like a flat image with no useful structure. A PDF/UA file carries the tags and labels that let assistive tools read the same content in a clear, meaningful way.
The main difference is not always visible. A PDF can look perfect to the eye, with clean headings, neat columns, sharp tables, and placed images, but still fail PDF/UA if the structure underneath the page is missing or wrong.
PDF/UA adds tagged content under the surface. Those tags identify what each part means, such as heading, paragraph, list, table, figure, link, or form field.
| What a Standard PDF May Show Visually | What PDF/UA Adds Under the Surface |
|---|---|
| A page that looks perfectly structured to the eye | Structure a machine can actually read |
| Text placed on the page | Machine-readable structure with correct semantics |
This is why a PDF that looks fine can still be unreadable to a screen reader. If the file has no real structure, the screen reader may read text out of order, skip labels, misunderstand tables, or announce visual parts with no useful meaning.
PDF/UA makes the invisible structure testable. It does not only ask whether the document looks accessible; it checks whether the content is tagged, ordered, labelled, and understandable to tools that users depend on.
What Is the Difference Between PDF/UA and WCAG?
WCAG explains what digital accessibility needs across websites, apps, documents, and other online content. PDF/UA explains how to meet those needs inside a PDF file.
They are complementary standards, not competing rules. WCAG gives the accessibility goal, while PDF/UA gives the PDF-specific structure that helps reach that goal. A simple way to read the difference is this.
| Standard | What It Answers | Example |
|---|---|---|
| WCAG | What must be accessible | Content structure, text alternatives, keyboard access, and readable order |
| PDF/UA | How a PDF should carry that accessibility | Tags, reading order, alt text, table headers, document language, title, and Unicode mapping |
One clear example is WCAG success criterion 1.3.1, Info and Relationships. This rule says that information, structure, and relationships must be available in a way software can understand.
Inside a PDF, PDF/UA helps meet that rule by requiring proper tags. A heading should be tagged as a heading, a list should be tagged as a list, and a table header should be connected to the right data cells.
So WCAG tells you the content relationship must be accessible. PDF/UA tells you how to build that relationship into the PDF through tags, reading order, labels, and other file-level accessibility rules.
The practical takeaway is simple. Use WCAG to understand the accessibility requirement, and use PDF/UA to make sure the PDF file carries that requirement correctly.
How Do You Check Whether a PDF Is PDF/UA Conformant?
Test a PDF with a checker such as veraPDF or PDF Accessibility Checker, then finish with a manual check for issues software cannot judge.
Automated validation can catch many technical problems. A checker can report missing tags, missing document language, missing metadata title, font or Unicode issues, broken structure, missing alt text fields, and whether the file claims PDF/UA correctly.
veraPDF is useful for standards-based validation. It reports whether the file passes or fails PDF/UA rules and shows the failed checks that need repair.
PDF Accessibility Checker, often called PAC, is useful for accessibility review. It can show problems in the tag structure, reading order, headings, tables, alt text, and other accessibility features that affect screen reader users.
The Matterhorn Protocol explains why software alone is not enough. It splits PDF/UA testing into 31 checkpoints and 136 failure conditions, but not every failure can be judged by a machine.
Some checks are machine-testable. A tool can usually detect whether the document language is missing, whether a title is missing, whether fonts are embedded, or whether a required tag is absent.
Other checks need human judgment. A person must decide whether the reading order actually makes sense, whether alt text describes the image correctly, whether table headers are meaningful, and whether the tags match the real purpose of the content.
No tool can fully certify PDF/UA on its own. The safe workflow is to run an automated checker, fix the reported technical issues, then review the document manually with accessibility and screen reader behavior in mind.
Is PDF/UA Required by Law?
PDF/UA is not a law by itself, but it is the accepted way to meet accessibility rules such as Section 508, ADA Title II, and the European Accessibility Act when PDF files must be accessible.
Most accessibility laws do not only care how a PDF looks. They care whether people using screen readers, keyboard navigation, and other assistive tools can access the same information and complete the same tasks.
The connection works in steps. Laws and public-sector policies often point to WCAG or wider accessibility requirements. PDF/UA gives PDF files a technical way to meet those requirements through tags, reading order, alt text, language, title, and other file-level rules.
That means PDF/UA is not usually named as the law itself. Instead, it acts as the practical PDF standard that helps prove compliance when an organization must provide accessible documents.
A PDF can also state that it aims to pass PDF/UA by using the pdfuaid identifier in the file metadata. That marker alone is not enough, though. The file still needs correct tags, structure, reading order, metadata, and manual accessibility review.
The plain link is that accessibility laws point to WCAG or accessible digital content, and PDF/UA shows how a PDF can carry those requirements correctly. For organizations that publish public forms, reports, policies, notices, or official documents, PDF/UA is the safest standard to follow.
How Do You Create a PDF/UA-Compliant Document?
Build accessibility in the source app first by adding real headings, alt text, and table headers. Then run a tagged PDF export and fix whatever the checker flags during remediation.
The best workflow starts during authoring, not after export. Fixing structure while writing or designing the document costs far less than repairing a finished PDF with broken tags, missing image descriptions, or confusing table structure. You can use this order below.
- Create the structure in the source file: In Word, use built-in heading styles, real lists, meaningful link text, table headers, and alt text for images that carry information. In InDesign, use paragraph styles, object export options, table structure, reading order tools, and accessible metadata.
- Add accessibility details before export: Set the document language, add a clear title, describe meaningful images with alt text, mark decorative visuals correctly, and make sure tables have proper header rows instead of only visual formatting.
- Export as a tagged PDF: Use the app’s tagged PDF export option so headings, lists, tables, images, links, and other document parts are carried into the PDF structure.
- Check the exported PDF: Run a PDF/UA checker to find missing tags, wrong reading order, missing alt text, title problems, unset language, table issues, font problems, or other accessibility failures.
- Fix issues in Acrobat or a dedicated tool: Use Acrobat or another PDF remediation tool to repair the tag tree, reading order, alt text, table headers, metadata, form labels, or other problems the checker reports.
The key is to build accessibility before the PDF exists. A clean source file usually creates a cleaner tagged PDF, while a poorly structured source file often creates a PDF that needs heavy remediation.
What's the Difference Between PDF/UA-1 and PDF/UA-2?
PDF/UA-1 is defined by ISO 14289-1:2014 and is built on PDF 1.7. PDF/UA-2 is defined by ISO 14289-2:2024, matches PDF 2.0, and improves the tag model for newer accessible PDF workflows.
PDF/UA-1 is still the version many accessibility checkers and production workflows focus on. It gives the established rules for accessible PDF files, including tags, reading order, alt text, language, metadata, Unicode mapping, and support for assistive technology.
PDF/UA-2 updates the standard for the PDF 2.0 era. It works with the newer PDF structure model and improves how modern tags, namespaces, document parts, and accessibility semantics can be represented inside a PDF.
The practical difference is adoption. PDF/UA-2 is the newer standard, but PDF/UA-1 is still the everyday target in many checking tools, remediation workflows, and client requirements.
So for now, most teams should understand both versions. Use PDF/UA-1 when the checker, client, or workflow asks for it. Use PDF/UA-2 when your tools support PDF 2.0-based accessibility and the receiving workflow can validate it properly.
How Do PDF/UA and PDF/A Differ?
PDF/A keeps a file readable over time, while PDF/UA makes sure everyone can read it, including people who use assistive technology. One is about long-term storage, and the other is about accessibility.
The one-line contrast is simple: PDF/A is for archiving, while PDF/UA is for accessible reading. PDF/A focuses on preservation rules such as embedded fonts, stable metadata, and future readability. PDF/UA focuses on tags, reading order, alt text, language, and structure that assistive tools can understand.
A file can also have dual conformance. That means the same PDF can meet PDF/A rules for long-term preservation and PDF/UA rules for accessibility at the same time.
For the full definition of the archival standard, read the dedicated What Is PDF/A guide.
Which ISO Standard Defines PDF/UA (ISO 14289)?
ISO 14289 defines PDF/UA. It adds accessibility rules on top of ISO 32000, the core PDF specification that defines the base PDF format.
Think of the standards in two layers. ISO 32000 explains how PDF works as a file format, while ISO 14289 explains what extra accessibility rules a PDF must follow to qualify as PDF/UA.
Those rules make PDF/UA an accessibility standard, not a separate file format. A PDF/UA file is still a PDF, but it must include correct tags, reading order, alt text, language, title, Unicode mapping, and other accessibility features.
The key relationship is simple: ISO 32000 is the foundation, and ISO 14289 adds the PDF/UA conformance rules on top of that foundation.
For the full explanation of the base PDF standard, read the dedicated ISO 32000 explained guide.
