WCAG 2.2 & PDF/UA: How to Make a PDF Technically Accessible

Making a PDF technically accessible means two standards have to work together: WCAG tells you what accessibility looks like at the content level, and PDF/UA (ISO 14289) tells you how to implement that accessibility inside the file itself. A PDF that satisfies both is one a screen reader can navigate, a keyboard can operate, and a person with low vision can actually read. This guide walks through how the two standards relate, the building blocks every accessible PDF needs, and how to test that you got it right.

WCAG and PDF/UA: the "what" and the "how"

The two standards are complementary, not competing. You generally want both.

WCAG (the Web Content Accessibility Guidelines, published by the W3C) is technology-neutral. It describes outcomes — text must have sufficient contrast, images need text alternatives, content must be operable by keyboard — without saying which bytes go where. WCAG applies to web pages, apps, and documents alike, which is exactly why most accessibility laws point to it. If you want the detail on the current version, see our explainer on WCAG 2.2 for PDFs.

PDF/UA (Universal Accessibility), formally ISO 14289, is PDF-specific. It defines the technical mechanics: which tags are required, how the structure tree must be built, where the reading order lives, what metadata the file must carry. PDF/UA is the rulebook for translating WCAG's outcomes into the internal anatomy of a PDF. There are two editions — PDF/UA-1 and the newer PDF/UA-2 — and the differences matter for tooling; we compare them in PDF/UA-1 vs PDF/UA-2.

A useful way to hold it in your head:

In practice, a well-tagged PDF/UA-conformant document will satisfy most of WCAG's document-relevant criteria, and a PDF built to meet WCAG will rely on the structures PDF/UA defines. They reinforce each other.

The POUR principles

WCAG organizes everything under four principles, abbreviated POUR. Every building block below maps back to one of them.

• Perceivable — Users must be able to perceive the information. Text alternatives, sufficient contrast, and content that does not rely on color or shape alone.
• Operable — Interface components must be operable. For PDFs this mostly means keyboard-operable forms and links, and a sensible reading order.
• Understandable — Content and operation must be understandable. A declared document language, predictable structure, clear labels.
• Robust — Content must be robust enough to work with assistive technology now and in the future. This is where tagging and valid structure do the heavy lifting.

Keep POUR in mind as a checklist of intentions; the building blocks below are the implementations.

The building blocks of an accessible PDF

An accessible PDF is the sum of a dozen concrete features. Skip any one and you can break the experience for someone relying on assistive technology.

Tags and the structure tree

This is the foundation. Tags are an invisible layer that labels every piece of content — this is a heading, this is a paragraph, this is a list, this is a table cell. Together they form the structure tree (also called the tag tree), the semantic skeleton a screen reader reads instead of the raw page. An untagged PDF is, to a screen reader, often just an undifferentiated wall of text or — worse — nothing at all. Tagging is so central that it has its own deep dive: PDF tags and reading order.

Logical reading order

Sighted readers infer order from layout. A screen reader follows the order encoded in the structure tree. If a two-column newsletter is tagged so the reader jumps from the top of the left column to the top of the right column mid-sentence, the document is technically tagged but practically broken. Reading order must follow the intended narrative, independent of where content sits on the page.

Real headings

Headings (H1, H2, H3…) are how screen-reader users skim. Most assistive technology lets users jump from heading to heading or pull up a list of all headings as an outline. That only works if headings are real structural tags — not just text that someone made big and bold. Headings should also be properly nested, without skipping levels arbitrarily.

Alternative text for images

Every image that conveys meaning needs a text alternative — alt text — so a screen reader can describe it. Decorative images that add nothing should be marked as artifacts so the reader skips them entirely. Good alt text is concise and conveys the image's purpose in context, not a literal pixel-by-pixel description. We cover the nuances in alt text for images in PDFs.

Accessible tables

Data tables need structural tags that distinguish header cells from data cells, and that associate each data cell with its row and column headers. Without that association, a screen reader reads a flat stream of numbers with no idea which column or row they belong to. Layout tables (used purely for positioning) should generally be avoided. See accessible tables in PDFs for how to tag them correctly.

Lists

Bulleted and numbered lists need proper list tags so assistive technology can announce "list, 5 items" and let users navigate within it. Faking a list with manual bullet characters and line breaks gives none of that structure.

Meaningful links

Links must be tagged as links and, ideally, have descriptive text. "Click here" repeated ten times tells a screen-reader user nothing; "Download the 2026 benefits guide" tells them exactly where the link goes. Bare URLs are also poor — they get read out character by character.

Interactive forms

Form fields must be keyboard-operable, presented in a logical tab order, and each field needs a programmatic label (and often a tooltip) so the screen reader announces what to enter. A blank box with no accessible name is unusable without sight. Forms are a frequent failure point; see accessible PDF forms.

Color and contrast

Text must meet WCAG contrast ratios against its background, and color must never be the only way information is conveyed. "Required fields are in red" fails for users who cannot perceive red; pair it with a label or symbol. Contrast and color-independence are content-level (WCAG) concerns that no amount of tagging fixes — you have to design for them.

Document language

The PDF must declare its primary language in its metadata (for example, en-US). Screen readers use this to load the correct pronunciation rules. Passages in a different language should be marked up individually. A missing language setting can make an English document read aloud with French phonetics — or refuse to read at all.

Document title and metadata

The file needs a human-readable document title in its metadata, and viewers should be set to display that title (rather than the file name) in the window. Title and language are small fields with an outsized impact on orientation, and both are mandatory under PDF/UA.

Bookmarks

For longer documents, bookmarks (an interactive outline, usually generated from the headings) give everyone — not only assistive-technology users — a way to jump between sections. They are recommended for any substantial document.

Selectable, not image-only, text

A PDF that is really a scanned image of a page contains no actual text — just a picture of words. Screen readers find nothing to read, and the text cannot be selected, searched, or reflowed. The fix is OCR (optical character recognition) to produce a real text layer, which then has to be tagged. If your document is a flat scan, that conversion is the very first remediation step.

PDF/UA conformance and the Matterhorn Protocol

PDF/UA conformance is not a vibe — it is a defined set of requirements in ISO 14289. To make those requirements testable, the PDF Association maintains the Matterhorn Protocol: a catalogue of failure conditions and checkpoints that map directly to PDF/UA's requirements. Each checkpoint describes a way a PDF can fail conformance — for example, "a figure has no alternative text" or "content is not tagged."

The Matterhorn Protocol splits checks into two kinds:

• Machine-checkable conditions, which automated tools can verify (is there a /Lang entry? is every content item tagged?).
• Human-verifiable conditions, which require a person's judgment (is the alt text meaningful? does the reading order actually make sense?).

That split is the key insight for testing: software can catch the mechanical failures, but only a human can confirm the document is genuinely usable.

How to test an accessible PDF

A credible accessibility check uses both automated and manual testing — neither alone is sufficient.

Automated checkers quickly catch the machine-checkable problems: missing tags, absent language, untagged images, no document title. They are fast, repeatable, and great for catching regressions and obvious gaps at scale. What they cannot do is judge meaning — an automated tool will happily pass alt text that says "image1.jpg," or a reading order that is technically present but nonsensical.

Manual screen-reader testing closes that gap. Opening the document with a screen reader and navigating it the way a real user would — tabbing through the form, jumping by heading, listening to how a table is read — surfaces the human-verifiable issues automated tools miss. Manual testing also includes checking the logical reading order, the quality of alt text, and keyboard operability end to end.

A practical workflow:

1. Run an automated check to fix the mechanical failures first.
2. Walk the document with a screen reader and keyboard to validate meaning, order, and operability.
3. Re-run the automated check to confirm nothing regressed.

For broader context on how PDF/UA relates to other PDF standards you may have heard of — particularly the archiving standard — see PDF/A vs PDF/UA. They are often confused, but only one is about accessibility.

Accessibility is not box-ticking; roughly 1 in 4 U.S. adults lives with a disability, and a properly built PDF is the difference between a document they can use independently and one that locks them out. The building blocks above are how you get there.

Key takeaways

• WCAG defines what accessibility means at the content level; PDF/UA (ISO 14289) defines how it is implemented inside the file. Aim for both — they are complementary.
• WCAG's POUR principles (Perceivable, Operable, Understandable, Robust) are the intentions; tags, reading order, headings, alt text, accessible tables, labeled forms, contrast, language, and a document title are the implementations.
• Tags and the structure tree are the foundation — an untagged PDF is largely invisible to a screen reader, and a scanned image-only PDF needs OCR before anything else.
• The Matterhorn Protocol translates PDF/UA requirements into checkable failure conditions, split between machine-checkable and human-verifiable.
• Test with both automated checkers (for mechanical failures) and manual screen-reader review (for meaning, order, and operability). Neither is sufficient on its own.