PDF/UA Explained: The Accessibility Standard Every Document Should Meet

If you have ever tried to read a poorly-made PDF with a screen reader, you already understand why PDF/UA exists. PDF/UA, short for "Universal Accessibility", is the ISO standard (ISO 14289) that defines what a truly accessible PDF looks like. It is the difference between a document that is technically a PDF and a document that anyone, including users with visual, motor, or cognitive disabilities, can actually read.

This guide explains what PDF/UA requires, why it matters more every year, and how to create files that pass.

Why PDF/UA exists

PDF was designed in the 1990s to preserve visual layout. It was never originally designed with assistive technology in mind. For decades, the format's flexibility led to documents that look correct but are useless for anyone who cannot see them, text rendered as images, reading order that jumps around the page, tables built out of disconnected text fragments.

PDF/UA was published in 2012 to codify what every PDF should do to be accessible. It does not invent new features. It enforces a strict subset of existing PDF accessibility features, so any compliant reader plus any compliant document combine into a predictable experience.

For a broader introduction to PDF accessibility, see our PDF accessibility guide and the related deep dive on accessibility tags in PDF.

What PDF/UA requires

A PDF/UA-compliant file must satisfy several core rules:

1. The file is tagged. Every piece of content, paragraph, heading, image, table cell, list item, sits inside a structure element that describes what it is.
2. Reading order is explicit. The tags form a tree, and a screen reader walks that tree top to bottom. The visual layout does not determine reading order, the tag tree does.
3. Text has a language declared. Both for the document as a whole and for any inline span that differs (so a screen reader knows when to switch voices).
4. All non-text content has alternative text. Photographs, charts, decorative images, everything either has alt text or is marked as artifact (decorative, skipped by screen readers).
5. Tables are structured. Headers are tagged as headers, data cells as cells, and the relationship between them is explicit.
6. Lists are tagged as lists. Not as a series of paragraphs starting with a bullet character.
7. No content relies only on color. A red asterisk in a form is fine; a red asterisk that is the only indicator of a required field is not.
8. The document has a logical title. Not "Untitled" or "Microsoft Word - draft7.docx". A real human-readable title that screen readers announce.
9. Security settings cannot block assistive technology. Even an encrypted PDF must let a screen reader read it.

If any of these fail, the file is not PDF/UA. Period.

How PDF/UA differs from WCAG

This question comes up constantly. WCAG (Web Content Accessibility Guidelines) is the broader, web-first accessibility framework. PDF/UA is the format-specific implementation for PDFs. They are complementary:

• WCAG tells you, at a high level, that all images need alt text.
• PDF/UA tells you exactly how that alt text must be stored in the PDF object tree to be reliably read.

If you have a legal obligation to comply with WCAG 2.2 Level AA (and increasingly, most organizations do), your PDFs almost certainly need to conform to PDF/UA-1 or the upcoming PDF/UA-2 to satisfy that obligation. The two standards are explicitly aligned.

Tools that help you reach PDF/UA

Creating an accessible PDF by hand is brutal. Use authoring tools that understand structure from the start:

• Microsoft Word, exports tagged PDFs if you use real styles (Heading 1, Heading 2) and set alt text on images.
• Adobe InDesign, the Articles panel and Tag Order panel let you control reading order.
• LibreOffice Writer, produces tagged PDFs from styled documents, with an "Archive PDF/A-1a" option that implies tagging.
• LaTeX with the tagged-pdf package, relatively new but workable for technical documents.

After authoring, validate the result with:

• PAC 2026 (PDF Accessibility Checker), the free de-facto industry tool from access for all.
• Adobe Acrobat Pro accessibility checker, convenient if you already own Acrobat.
• veraPDF, open-source validator that also handles PDF/A.

These tools find missing alt text, broken reading order, untagged content, and other PDF/UA violations.

Common mistakes that break PDF/UA

A surprising number of documents that "look fine" fail validation because of small details:

• A logo at the top of the page tagged as an image instead of an artifact, with no alt text, every page starts with the screen reader saying "image".
• A table built as a grid of text boxes instead of a real table, the screen reader reads row 1 column 1, then jumps somewhere unexpected.
• Decorative dividers tagged as paragraphs, the screen reader announces "paragraph" repeatedly for nothing.
• A form field with a visible label on the page but no programmatic relationship to the field, the screen reader hits an unlabeled input.
• Headings styled with manual bold and large font instead of real heading tags, the user cannot navigate by heading.

For more on signing accessible forms, see how to fill out a PDF form.

Why this is becoming non-negotiable

Across 2024 and 2025 several regulations came into effect that quietly raised the stakes:

• The European Accessibility Act requires accessible documents from any business serving EU consumers from June 2025 onward.
• The U.S. Department of Justice ruling under Title II of the ADA (effective for state and local governments from 2026) requires conforming PDFs.
• Many corporate procurement processes now require Voluntary Product Accessibility Templates (VPATs) that include PDF/UA compliance.

This is no longer a niche concern. If you publish documents, your PDFs need to pass.

Takeaway

PDF/UA is the standard that closes the gap between "this looks like a PDF" and "this is a usable document for everyone." Create files with real headings, real lists, real tables, alt text on every image, and a declared language. Validate before you publish. The same discipline that makes a file accessible also tends to make it cleaner, more searchable, and easier to convert, for example, if you ever need to convert it to Word or back into Markdown. At Docento.app, browser-based editing preserves existing structure, so a properly tagged file stays tagged after you edit it.