What makes a PDF accessible — and why it matters

SpecSpec: ISO 14289-1ISO 14289-1SpecSpec: ISO 14289-2ISO 14289-2SpecSpec: ISO 32000-2ISO 32000-2SpecSpec: WCAG 2.2WCAG 2.2

At a glance

An accessible PDF is one that a person who cannot see the page can still read, in the order you meant, with every picture described and every heading announced as a heading. This page explains how a PDF carries that meaning — tagged content, a structure tree, reading order, alternative text — and why it is worth getting right.

Why this matters

A PDF, by default, is a set of marks at coordinates. It says put this glyph here and paint this image there. It does not, on its own, say this is a heading, this row belongs to that column, or this picture shows a signed contract. A sighted reader fills those gaps instantly from layout. A screen reader cannot. It has only what the file actually states.

So an untagged PDF can look perfect and read as nonsense: a two-column page announced straight across, a data table flattened into a stream of unrelated numbers, a chart that is simply silent. The information is on the page. It is just not reachable. For millions of people that is the difference between a document they can use and one they cannot — and, increasingly, the difference between a compliant public service and a legal exposure.

The short version

• A tagged PDF carries a parallel layer of meaning over the visual marks: this run of glyphs is a heading, that block is a list, this region is a table.
• Those tags hang on a structure tree — a logical outline of the document, separate from where things sit on the page (SpecSpec: ISO 32000-2, §14.7ISO 32000-2 §14.7).
• The tree fixes the reading order, so content is presented in the sequence you intended, not the order glyphs happened to be painted.
• Non-text content carries a text equivalent: an /Alt description for an image, replacement text for a glyph run a reader would otherwise mangle (SpecSpec: ISO 32000-2, §14.8ISO 32000-2 §14.8).
• PDF/UA (ISO 14289) is the standard that says when all of this is present and correct. It is what “accessible PDF” means as an engineering claim, not a marketing one (SpecSpec: ISO 14289-1ISO 14289-1).

How NextPDF approaches it

Two layers, one file

Think of an accessible PDF as two layers that travel together. The content layer is what you see: glyphs, lines, images, placed at coordinates. The structure layer is what it means: a tree of elements — document, headings, paragraphs, lists, tables, figures — that names each piece of content and puts it in order.

The two are stitched together by marked content. Each meaningful run on the page is wrapped and given an identifier; the matching structure element points back at that identifier. That link is what lets assistive technology walk the logical tree and, at every node, find the exact bytes on the page it describes. Get the link right and a heading is announced as a heading; get it wrong and the structure is a fiction that does not match what is shown.

Reading order lives in the tree, not the layout

This is the idea that surprises people. The order a screen reader uses is the order of the structure tree, and that is independent of where content falls on the page (SpecSpec: ISO 32000-2, §14.7ISO 32000-2 §14.7). You can paint a sidebar last and a footnote first; as long as the tree threads them in the intended sequence, the document reads correctly. Conversely, a beautifully laid-out page with a scrambled tree reads beautifully wrong. Layout is for eyes. The tree is for everyone else.

A text equivalent for everything that is not text

A photograph, a logo, a chart, a decorative rule — none of these are words, so none of them announce anything by default. Tagged PDF closes that gap with alternate descriptions: an image’s /Alt text describes what it conveys, and /ActualText supplies a clean replacement for a glyph run that would otherwise be read wrong, such as a ligature or a stylised drop-cap (SpecSpec: ISO 32000-2, §14.8ISO 32000-2 §14.8). Purely decorative marks are tagged as artifacts so they are skipped rather than read as noise. The rule is simple: if it carries meaning, it gets a text equivalent; if it does not, it gets marked out of the way.

How a screen reader actually consumes the file

When assistive technology opens a tagged PDF, it does not read the page. It reads the tree, and uses the marked-content links to surface each element’s text in order.

1. OpenThe reader finds the structure tree root in the document catalog, the entry point to the logical document.
2. Walk the treeIt traverses the logical hierarchy — document, headings, paragraphs, lists, tables — in structure order.
3. Map the roleEach structure type maps to a familiar role, so a heading is announced as a heading and a list as a list.
4. Read the contentFor each element it reads the linked page text, or the alternate description when the content is an image.
5. Skip the noiseAnything tagged as a decorative artifact is passed over, never spoken.

How a screen reader consumes a tagged PDF: it opens the document, finds the structure tree root, walks the logical tree in order, maps each element to a familiar role, reads the element's text or its alternate description, and skips anything tagged as decorative. The reading sequence comes from the tree, not from where content sits on the page.

Because the sequence is the tree’s sequence, a correctly tagged two-column report reads down one column and then the other, a table reads cell by cell with its headers, and a figure announces its description instead of falling silent. The reader never has to guess the author’s intent, because the intent is recorded in the file.

The standard that pins it: PDF/UA

All of this becomes a checkable claim under PDF/UA. PDF/UA-1, published as ISO 14289-1, states the file-level requirements for an accessible PDF on top of the tagged-PDF model (SpecSpec: ISO 14289-1, §7ISO 14289-1 §7). PDF/UA-2, ISO 14289-2, carries those requirements onto the PDF 2.0 baseline and refines how real content maps to the structure model (SpecSpec: ISO 14289-2, §8ISO 14289-2 §8). PDF/UA governs the file’s structure; the broader Web Content Accessibility Guidelines describe the outcomes a document is measured against, and a conformance claim names the level it actually reached (SpecSpec: WCAG 2.2, §5WCAG 2.2 §5). The two work together: PDF/UA says the machinery is present and correct, WCAG frames what good looks like for a human.

Human-factors note:Human-factors note

Accessibility is not a feature you bolt on at the end. A tag tree added after layout, by guessing reading order from coordinates, is exactly the fiction that reads wrong. The meaning has to come from the document’s structure as it is authored — the heading is a heading when it is written, not when a tool infers it later. Build the structure as you build the content, and the accessible file is the same file, not a second one.

Practical example

Tags are not visible, so the only honest way to check them is to look at the structure a tool reports. A minimal accessible page has a real tree: a document root, a heading, a paragraph, and a figure that carries a description rather than silence.

StructTreeRoot
 └─ Document
     ├─ H1            "Quarterly Report"
     ├─ P             "Revenue rose across every region this quarter."
     └─ Figure        /Alt "Bar chart: revenue by region, all four up"

A reader walking this tree announces a level-one heading, reads the paragraph, then reads the figure’s description — in that order, regardless of where each element was painted. Strip the tree away and the same page becomes three disconnected runs of glyphs and one silent rectangle. The pixels are identical. The experience is not.

Common misconception

The frequent belief is that a PDF “is accessible because the text is selectable”. Selectable text means the glyphs are real characters rather than a scanned picture — necessary, but nowhere near sufficient. Selectable text with no structure tree still has no headings, no reading order, no table relationships, and no image descriptions. Accessibility is about structure and meaning, not merely the presence of extractable characters. A file can pass copy-and-paste and fail a screen reader completely.

A second trap is treating “tagged” as a yes/no badge. A file can be tagged and still wrong: tags that mislabel content, a tree whose order does not match the intent, images with empty or useless /Alt text. Tagged is the start of the conversation, not the end of it.

Limits and boundaries

This page explains the concepts and the standards that define them. It is not a conformance certificate, and no tool can grant one on its own.

PDF/UA structural accessibility — edition availability

Edition	Availability
Core	○ Core writes tagged PDF: it emits a structure tree, marks decorative content as artifacts, and carries the alternate text you supply.
Pro	○ Adds richer structure mapping for complex layouts — multi-level tables, lists, and figures — so the tree better matches the intended reading order.
Enterprise	○ Adds a structural conformance check and report. It remains a structure check, not a certification — the final determination belongs to a validator and a human reviewer.

Two boundaries are worth stating plainly. First, the engine can produce correct structure, but it cannot judge editorial quality: it will faithfully carry an /Alt description that says “image”, and that is on the author, not the engine. Accessibility is a collaboration between a tool that records meaning and a human who supplies it. Second, an automated pass — including a validator like veraPDF — confirms the machinery is present and well-formed. It does not confirm that a person using a screen reader can actually understand the result. Final sign-off is human. See validating PDF/A and PDF/UA for how that automated check fits in.

Related docs

• The standards landscape — where PDF/UA and WCAG sit in the wider federation of standards NextPDF tracks.
• Fonts: the hard part — why text that looks right can still be unsearchable, and how that touches accessibility.
• What a PDF actually is — the object model the structure tree lives inside.
• Validating PDF/A and PDF/UA — how to run an automated conformance check, and what it can and cannot tell you.

Glossary

• Tagged PDF — a PDF that carries a parallel layer of structure tags over its visual content, so assistive technology can reach the document’s meaning, not just its marks.
• Structure tree — the logical outline of a document (root, headings, paragraphs, lists, tables, figures), recorded independently of page layout and used to determine reading order.
• Reading order — the sequence in which content is presented to a reader, taken from the structure tree rather than from where glyphs were painted.
• Alternative text — a text equivalent for non-text content: an /Alt description for an image, or /ActualText replacement for a glyph run that would otherwise be read incorrectly.
• Artifact — content tagged as decorative (a rule, a background, a watermark) so a reader skips it instead of announcing it.
• PDF/UA — PDF/Universal Accessibility, ISO 14289. The standard that defines when a tagged PDF is genuinely accessible. PDF/UA-1 is ISO 14289-1; PDF/UA-2 is ISO 14289-2, on the PDF 2.0 baseline.