What is a tagged PDF, and why accessibility needs one
A PDF stores characters at coordinates. Tagging is the layer that tells software what those characters mean.
The problem tagging solves
A PDF records where each character sits on the page and nothing about what it is. A heading is not stored as a heading — it is stored as some glyphs that happen to be larger and bolder. A table is not a table; it is text positioned in a grid and some lines drawn nearby. A column break is a gap.
Sighted readers reconstruct all of that instantly from visual convention. Software cannot, and a screen reader has nothing to work with: it does not know that a run of text is a level-two heading, that two blocks are columns to be read in sequence, or that a number belongs to the row labelled "March".
Tagging adds that missing layer. A tagged PDF carries a parallel structure tree describing the document logically — this is an H1, this is a paragraph, this is a table with these headers, these are list items, this image means this — while the visible page stays exactly as it was.
What a tagged PDF contains
Four things, roughly in order of how much difference they make:
- A structure tree. Headings at their real levels, paragraphs, lists, tables with header cells identified. This is what lets a screen reader user jump between headings instead of listening linearly to forty pages.
- A defined reading order. Explicit sequence, independent of where things sit on the page — which is the difference between a two-column page read correctly and one read straight across, alternating between columns.
- Alternative text for images. A description of what each image conveys, or a marker saying it is decorative and should be skipped.
- Language and metadata. A declared document language so a screen reader pronounces the text correctly, plus a title that gets announced instead of the filename.
A scan can never be accessible
This is worth stating plainly because it defeats a lot of well-intentioned compliance effort. A scanned document contains no text at all — every page is a photograph. There is nothing to tag, nothing to read aloud, and nothing to extract.
A screen reader encountering one announces an image and stops. No amount of tagging fixes that, because tagging describes structure and there is no content to give structure to.
The only route is optical character recognition first, to produce actual text, and then tagging on top of that. Which means a scanned archive is not one step away from accessible — it is two, and the first one is the expensive one. Organisations that have digitised by scanning frequently discover this late.
What the rules actually require
In the United States, Section 508 of the Rehabilitation Act requires federal agencies to make electronic documents accessible, and the Americans with Disabilities Act has been read by courts to cover public-facing digital content. In the European Union, the Web Accessibility Directive covers public sector bodies and the European Accessibility Act extends obligations to many private services.
The technical target these converge on is WCAG — the Web Content Accessibility Guidelines — usually level AA. For PDFs specifically there is also PDF/UA, an ISO standard defining what a universally accessible PDF must contain, which in practice means fully tagged with a correct reading order.
That overlaps with archiving: PDF/A's level A conformance requires the same tagging, which is why a document can pass PDF/A-1b on appearance alone and fail PDF/A-1a for having no structure.
This is general information rather than legal advice, and the specific obligation depends on your organisation and jurisdiction.
Getting it right at the source
The single most effective habit costs nothing: use real heading styles in whatever produced the document. A Word file where headings are actual Heading 1 and Heading 2 styles exports to a tagged PDF with a correct structure tree automatically. The same document where headings are just bold 16pt text exports to an untagged one, and fixing it afterwards is manual work.
The same applies to lists made with the list tool rather than typed hyphens, tables built as tables rather than aligned with tabs, and alternative text added to images at the point of insertion.
Remediating an existing untagged PDF is genuinely laborious, and it is worth knowing that going in. Tagging at the source is nearly free; tagging afterwards is a project.
Frequently asked questions
What is a tagged PDF?
A PDF carrying a structure tree that describes the document logically — headings, paragraphs, lists, tables, reading order and image descriptions — alongside the visible page. It is what allows a screen reader to navigate the document rather than read it as an undifferentiated block.
How do I know if a PDF is tagged?
Most PDF readers show it in the document properties, often as a "Tagged PDF: Yes/No" line. A practical hint: if selecting text produces a sensible reading order on a multi-column page, the file is probably tagged.
Can a scanned PDF be made accessible?
Not directly. A scan has no text, only images of pages, so there is nothing to tag or read aloud. It has to go through optical character recognition first to produce real text, and only then can it be tagged.
Is a PDF accessible if I can select the text?
No — selectable text is necessary but not sufficient. Without tagging there is still no heading structure, no defined reading order and no image descriptions, so a screen reader gets a flat stream of words.
What is PDF/UA?
An ISO standard defining the requirements for a universally accessible PDF: full tagging, a correct reading order, alternative text and declared language. It is the PDF-specific counterpart to WCAG.
What is the easiest way to produce an accessible PDF?
Use real heading styles, real lists and real tables in the source document, and add alternative text to images before exporting. Exporters carry that structure into the PDF automatically. Adding it afterwards is manual and slow.