What is PDF/UA? The accessible PDF standard explained

PDF/UA, short for PDF/Universal Accessibility, is the ISO standard(opens in a new tab) (ISO 14289) for accessible PDF documents. The standard defines what a file must contain so that people using screen readers, magnifiers, braille displays, and voice control can read and interact with it reliably. It’s published and maintained by the International Organization for Standardization (ISO) in collaboration with the PDF Association(opens in a new tab).

A conformant file is a properly tagged PDF that carries enough structural and semantic information for assistive technology to interpret reading order, headings, tables, alternate text for images, language metadata, and form labels. A standard PDF without that information may look identical onscreen but is partly or completely unusable for the same readers.

This post covers what the standard requires, how it relates to WCAG and accessibility regulations like the EAA and ADA, how to confirm conformance, and how its two current parts (PDF/UA-1 and PDF/UA-2) differ.

PDF/UA at a glance

Before going deeper, here’s a quick overview of the basics:

• Name — PDF/UA (PDF/Universal Accessibility)
• Standard — ISO 14289
• Current parts — PDF/UA-1(opens in a new tab) (ISO 14289-1:2014, based on PDF 1.7) and PDF/UA-2(opens in a new tab) (ISO 14289-2:2024, aligned with PDF 2.0)
• Identifier — Conformant files declare which part of the standard they meet via an XMP metadata entry: pdfuaid:part=1 for PDF/UA-1 and pdfuaid:part=2 for PDF/UA-2. Validators check for this entry as part of conformance testing — if it’s missing, the file isn’t treated as PDF/UA, even if the structure meets the standard.
• Core idea — A PDF file must carry structural and semantic information — known as a tagged PDF — so assistive technology can understand it.
• What it isn’t — A guarantee of legal compliance, a replacement for manual review, or the same thing as WCAG.

What does PDF/UA stand for?

PDF/UA stands for Portable Document Format/Universal Accessibility. It’s the short form used throughout ISO 14289 and in most accessibility tooling.

A brief history of PDF/UA

To understand PDF/UA, it helps to look at how it came to be. PDF itself became an open ISO standard(opens in a new tab) in 2008 as ISO 32000-1, which codified PDF 1.7. That was the file format. Accessibility came shortly after:

• ISO 14289-1:2012 — The first edition of PDF/UA-1, and the initial accessibility standard for PDF.
• ISO 14289-1:2014 — The revised edition, and the version most validators still target today.
• ISO 14289-2:2024 — PDF/UA-2, aligned with PDF 2.0 (ISO 32000-2). It updates the requirements to reflect modern authoring and newer PDF features.

PDF/UA didn’t come out of nowhere. It was built on years of work around tagged PDFs in Adobe’s own specifications and on input from accessibility advocates who needed a single, testable standard for what an accessible PDF looks like.

How PDF/UA works: tagged PDFs

The mechanism behind PDF/UA is something called a tagged PDF(opens in a new tab). An untagged PDF is, as far as software is concerned, a collection of glyphs positioned on a page. A screen reader can try to guess what’s a heading, what’s a paragraph, and what order to read things in, but at the end of the day, it’s still guesswork.

A tagged PDF, on the other hand, adds a separate structure tree to a file. Each piece of content — whether it’s a heading, a paragraph, a list item, a table cell, or a figure — is labeled with a tag that describes what it is. A tagged PDF also records:

• A logical reading order, independent of where things sit on the page.
• Alternate text for images and other non-text content that carries meaning.
• Decorative elements marked as artifacts, so assistive technology can ignore them.
• Language metadata at the document and span level.
• Table structure that distinguishes header cells from data cells.
• Form field labels, descriptions, and tab order.
• Unicode mappings, so selected or spoken text matches the visible glyphs.

PDF/UA turns tagging from a nice-to-have into a requirement, and it adds conformance rules that describe exactly what has to be present and what must be avoided.

Standard PDF vs. PDF/UA

The following table shows the practical differences between a typical PDF file and one that conforms to PDF/UA. The comparison is feature-level, and not a comparison between standards.

What PDF/UA actually requires

The full standard is dense, but the practical requirements fall into a handful of categories: document-level requirements, content structure, meaningful non-text content, tables, forms, and navigation.

Document-level requirements

• The document must be tagged.
• It must declare a primary language (for example, en-US).
• It must have a title in the metadata, and that title should be shown in place of the file name when a viewer displays it.
• Encryption must not block assistive technology from reading the content.

Content structure

• Headings, paragraphs, lists, tables, and figures must be identified with the correct structural tags.
• Headings need to reflect the real hierarchy of the document. Don’t skip heading levels for visual effect.
• Reading order must be logical, not based on the physical position of content on the page.

Meaningful non-text content

• Figures, charts, and icons that convey meaning need alternate text or another accessible description.
• Purely decorative content must be marked as an artifact so it isn’t announced.

Tables

• Tables need real row and column structure.
• Header cells must be distinguishable from data cells.
• Complex tables need scope or header associations so cells can be read in context.

Forms

• Interactive form fields must have labels and, where useful, tooltips or descriptions.
• Focus order must make sense to someone using only a keyboard or screen reader.

Navigation

• Links and cross-references must use real PDF structures rather than visual imitations.
• Bookmarks (the document outline) need to mirror the heading structure when present.

For a complete and testable list of the ways a file can fail PDF/UA-1, the PDF Association publishes the Matterhorn Protocol(opens in a new tab), a reference document that catalogs every failure condition in the standard. Validators use it as the basis for automated checks.

What PDF/UA isn’t

Just as important as knowing what PDF/UA covers is knowing what it doesn’t, because there are a lot of misunderstandings in this space, and those misunderstandings often lead to wasted effort and false assurance.

PDF/UA isn’t WCAG. The Web Content Accessibility Guidelines(opens in a new tab) cover digital content broadly, including websites, applications, and documents delivered online. PDF/UA, on the other hand, covers the PDF file format specifically. The two overlap in spirit, but they aren’t interchangeable, and passing one doesn’t mean you’ve met the other.

PDF/UA isn’t legal compliance. Regulations like the European Accessibility Act(opens in a new tab) and Title II of the Americans with Disabilities Act (ADA)(opens in a new tab) cite WCAG, procurement standards, and general accessibility requirements. PDF/UA is a strong technical control inside those frameworks, but no regulator is going to say “ship a PDF/UA file and you’re done.”

PDF/UA isn’t automatic. A file exported from Word or generated by a converter may or may not conform, even if the authoring tool claims PDF/UA support. Tags can be missing, wrong, or logically broken, and reading order often drifts after layout-heavy conversions.

PDF/UA isn’t the whole accessibility story. A PDF/UA-conformant file can still be hard to use if the alternate text is vague, the source content is poorly structured, or the viewer renders it in a way that strips the tags. As a result, manual review is part of any credible process.

Is PDF/UA the same as WCAG?

No. WCAG applies to web content and covers a broader set of success criteria, including color contrast and time-based media. PDF/UA applies specifically to PDF files and defines the file-format requirements needed to make a PDF accessible. A PDF can meet PDF/UA and still fail WCAG on contrast or non-PDF considerations, and a webpage can meet WCAG without any bearing on PDF/UA. The two are complementary rather than interchangeable.

PDF/UA and accessibility law

PDF/UA matters more today than it did even five years ago, in large part because accessibility regulation has finally caught up with digital documents. Here’s a quick look at some of the most relevant rules:

• European Accessibility Act (EAA). Enforced from June 2025, the EAA applies to businesses with more than 10 employees or more than €2 million in revenue that sell certain products and services into the EU. Accessible documents are part of the scope for a wide range of organizations, including banks, e-commerce, and transport.
• EN 301 549. The European standard for accessible information and communication technology (ICT) procurement references WCAG, and accessible PDFs are a recurring expectation in tenders and audits.
• ADA Title II (US). Updated rules require state and local governments to make digital content, including PDFs, conform to WCAG 2.1 Level AA. Compliance deadlines are tiered by entity size, with larger public entities already in scope and smaller ones following on a staggered timeline.
• Section 508 (US). Federal agencies and their suppliers have to follow Section 508, which adopts WCAG 2.0 Level AA and addresses PDFs as part of electronic content.

In practice, PDF/UA adoption has visible institutional traction. The US Library of Congress added PDF/UA to its list of preferred archivable file formats in 2012, citing it as “a preferred format for page-oriented content.” The US Access Board’s 2015 Section 508 rulemaking identified PDF/UA as equivalent to WCAG 2.0 for accessible federal electronic content. In the EU, public-sector procurement specifications under the European Accessibility Act increasingly name PDF/UA explicitly, particularly for banks, transport authorities, and government agencies bound by the 2025 enforcement deadline. The PDF Association maintains the Matterhorn Protocol(opens in a new tab) as the conformance test catalog these institutions reference.

Across all of these, PDF/UA is the practical technical target for the document layer. When a procurement team asks for “accessible PDFs,” it usually means files that meet PDF/UA-1 and pass validation, alongside a manual review.

How to tell whether a PDF is PDF/UA conformant

A common misconception is that a file is automatically PDF/UA conformant because it was exported from software that advertises the feature. Unfortunately, that’s not how it works. To actually confirm conformance, validation happens in three layers.

Automated validation

Open source and commercial validators check a file against the PDF/UA specification and the Matterhorn Protocol. The most widely used is veraPDF(opens in a new tab), an open source conformance checker supported by the PDF Association. Another common option is PDF Accessibility Checker (PAC(opens in a new tab)), which is developed by Access for All and reports findings against both PDF/UA and WCAG. Nutrient is also developing its own PDF/UA validator, giving teams that already use Nutrient for tagging and remediation a way to validate in the same workflow.

A typical veraPDF command-line validation looks like:

verapdf --flavour ua1 --format text document.pdf

A conformant file returns a clean pass:

PASS PDF/UA-1
0 failedRules

A failed validation identifies the specific Matterhorn checkpoint that failed:

FAIL PDF/UA-1
Rule 7.1-1 — Real content not contained inside structure tree
  Failed checks: 3

If you need to check or set the PDF/UA identifier programmatically — for example, when a converter strips the metadata — Python’s pikepdf library exposes the XMP entry directly:

import pikepdf

with pikepdf.open("document.pdf") as pdf:
    xmp = pdf.open_metadata()

    # Check the current PDF/UA identifier.
    print(xmp.get("pdfuaid:part"))

    # Set the identifier to declare PDF/UA-1 conformance.
    xmp["pdfuaid:part"] = "1"
    pdf.save("document-pdfua.pdf")

Automated tools are great at catching the mechanical failures: missing tags, absent titles, language not set, broken tables, and incorrect artifacts. However, they can’t tell you whether the tags describe the document truthfully, which is why manual review is also part of the process.

Manual review

For the issues validators cannot catch, a reviewer — ideally someone who uses assistive technology in their day-to-day work — checks the things that require human judgment:

• Does the reading order reflect how a human would read the document?
• Are heading levels used to describe structure, not to style text?
• Is alternate text informative, or is it a placeholder such as “image”?
• Are complex tables comprehensible when read cell by cell?
• Can a form be completed with only a keyboard?

Delivery review

Finally, if the PDF is consumed inside an application or browser, the viewer has to preserve accessibility too. A tagged PDF rendered by an inaccessible viewer is still an inaccessible reading experience. Keyboard focus, color contrast, and semantic rendering all live at the delivery layer, which means the viewing experience matters just as much as the document itself.

PDF/UA-1 vs. PDF/UA-2

There are two current parts of the ISO 14289 standard, and the choice between them affects tooling, validators, and how procurement teams evaluate the output. The table below summarizes the practical differences.

Which one to target

For most teams in 2026, PDF/UA-1 is still the practical target — it’s the version validators support and tooling matures around. PDF/UA-2 is forward-looking; pair both where possible. For procurement and compliance specifics on which version to name in RFPs, see our PDF/UA compliance guide.

How PDF/UA fits with related standards

Something that trips people up when they’re first learning about PDF/UA is the sheer number of acronyms that come up alongside it. Here’s how some of the most common ones line up:

Put another way, PDF/UA is the document-format answer, while WCAG and regulatory frameworks set the broader bar that organizations are measured against.

How accessible PDFs actually get produced

Of course, understanding what PDF/UA is only gets you so far; at some point, you also need to know how to produce files that meet the standard. In our experience, most teams go through some mix of the following steps:

1. Author with structure. Use real headings, real lists, real tables, and descriptive link text in the source file. Good structure upstream is the biggest single lever.
2. Convert with tagging enabled. When exporting from Word, InDesign, or a server-side converter, make sure tags and language metadata come through. Check the result. Don’t trust the checkbox.
3. OCR scanned content. An image of text isn’t accessible. Scanned PDFs need an accurate text layer before tagging is useful.
4. Auto-tag or remediate. For libraries of legacy PDFs, manual remediation per file is slow and expensive. Server-side auto-tagging applies structure, reading order, and alternate text at scale. Then it flags exceptions for human review.
5. Validate. Run veraPDF or a comparable checker. Address every reported failure.
6. Review manually. Especially for complex tables, form flows, and documents with a lot of figures.
7. Deliver through an accessible viewer. If end users open the PDF inside your application, the viewing layer has to render tagged content as semantic HTML and support keyboard and screen reader navigation.

Conclusion

Accessibility in digital documents is no longer a nice-to-have — it’s a baseline expectation, and one that’s increasingly backed up by regulation on both sides of the Atlantic. PDF/UA gives teams a concrete, testable way to answer the question of what an accessible PDF actually looks like, and it’s the standard most procurement teams, auditors, and accessibility advocates refer to when they ask for one.

That said, PDF/UA is one piece of the puzzle. It works best alongside good authoring practices, manual review, and an accessible delivery experience. When those pieces come together, the result is documents that more people can actually read and use.

Further reading

If you want to go deeper after this post, here are a few good next stops:

• The PDF Association distributes PDF/UA-1(opens in a new tab) at no cost through its PDF/UA bundle, and ISO sells the full text of PDF/UA-2(opens in a new tab).
• Our PDF/UA compliance guide walks through a working checklist tied to implementation — what to look for in source content, conversion, remediation, and delivery.
• For a broader view of how the document standard and our product capabilities line up, the PDF/UA readiness overview is a good place to start.
• If you’re working with PDF/A (the archival sibling standard) at the same time, refer to what is PDF/A? for how the two standards overlap and where they differ.
• For the broader picture across PDF accessibility — including WCAG 2.2 and Section 508 — see PDF accessibility: requirements, standards, and tools.
• For an overview of how accessibility standards apply to documents specifically, see WCAG 2 accessibility requirements for documents.

And if the job in front of you is converting or auto-tagging documents at scale, we have a few different paths depending on where processing happens:

• Use Nutrient Java SDK, .NET SDK, or Python SDK to convert Word documents, PDFs, and other sources to PDF/UA inside your own infrastructure. For step-by-step guides, see converting PDFs to PDF/UA in Java and Python, or converting Word documents to PDF/UA in Java and Python.
• Use Nutrient Document Engine, either self-hosted or Nutrient-managed, for document processing that includes PDF/UA output as part of a broader pipeline.
• Use our Accessibility API, a managed cloud endpoint, to send a PDF and get a tagged PDF/UA file back.
• Use Nutrient Web SDK accessibility features for accessible viewing in the browser, including keyboard navigation, semantic HTML rendering, and WCAG 2.2-aligned color contrast.

To see everything in action, or to talk through your specific use case with someone on our team, get in touch.

FAQ