Accessible PDFs: Tags, Reading Order and Alt Text That Matter

A PDF that looks perfectly organised on screen can be complete nonsense to a screen reader, because the visual layout and the underlying content order are two independent things. Fixing accessibility is mostly about making them agree.

How a screen reader reads a PDF

It does not look at the page. It walks a structure tree of tags — headings, paragraphs, lists, tables, figures — in the order they appear in that tree. If the document has no tags, the reader falls back to the raw content stream, which is the order the generator happened to write the glyphs in. For a two-column layout, that frequently means reading across both columns, line by line, producing interleaved gibberish.

The five fixes with the highest impact

1. Tag the document at all. An untagged PDF is the baseline failure; everything else is refinement.
2. Use real heading tags in a sensible hierarchy — H1, then H2, no skipping levels. Screen reader users navigate by heading the way sighted readers skim.
3. Fix the reading order so it matches the visual order, column by column, including sidebars and pull quotes.
4. Add alt text to every meaningful image, and mark purely decorative images as artifacts so they are skipped instead of announced.
5. Set the document language, so the reader uses the correct pronunciation rules.

Tables specifically

A table needs header cells marked as headers and associated with their data cells. Without that, a screen reader announces a stream of values with no indication of which column or row they belong to. For anything beyond a simple grid, add scope attributes; for tables with merged cells, expect to do the association manually.

Alt text that is actually useful

• Describe the information the image conveys, not the image. 'Revenue grew 40% year on year' beats 'bar chart'.
• For charts, put the underlying numbers in a caption or adjacent table rather than cramming them into alt text.
• Do not begin with 'image of' — the reader already announces that.
• Logos: the organisation name is the alt text.
• Decorative rules, borders and background textures: mark as artifact, no alt text.

Forms

Every field needs a tooltip or label that describes what to enter, and the tab order must follow the visual order. A form where tab jumps from the first field to the signature block and back is unusable without sight, even though it fills in fine with a mouse.

Testing without specialist software

Two quick checks catch most problems: turn on a reflow view and see whether the content order still makes sense, and extract the text to a plain file and read it top to bottom. If the plain text reads sensibly, the reading order is broadly right. Then run a formal accessibility check for the tagging details.

The standards you are actually being measured against

Three names come up constantly in accessibility work and it helps to know what each one actually governs. WCAG 2.2 is the Web Content Accessibility Guidelines, and although it was written for web pages, most procurement policies and legal frameworks apply its success criteria to PDFs as well, because a PDF opened in a browser is, functionally, a web document. PDF/UA — formally ISO 14289 — is the standard written specifically for PDF structure: it defines what a conforming tag tree, reading order and metadata block must look like at the file-format level. WCAG tells you what experience a disabled user must be able to have; PDF/UA tells you how a PDF has to be built to make that experience possible.

The two overlap heavily but are not identical. A document can satisfy most of WCAG 2.2's success criteria for perceivable and operable content while still failing PDF/UA's stricter machine-checkable rules about tag nesting or artifact marking. Conversely, a file can pass an automated PDF/UA checker on every rule it can test and still be a poor experience, because tools cannot verify that alt text is actually meaningful — only that it exists. Treat automated conformance as the floor, not the ceiling.

Which WCAG 2.2 criteria matter most for PDF work

• 1.1.1 Non-text Content — the alt text requirement covered above, applied to every image, form field icon and embedded chart.
• 1.3.1 Info and Relationships — the requirement that a table's structure, a list's list-ness, and a heading's level are conveyed in tags, not just visually implied by indentation or font size.
• 1.3.2 Meaningful Sequence — this is the reading-order requirement in formal language; content must be presentable in an order that preserves its meaning.
• 2.4.6 Headings and Labels — headings must describe the section that follows them, not just look like headings visually.
• 4.1.2 Name, Role, Value — every interactive form field must expose what it is and what state it's in to assistive technology, not just to the eye.

Common mistakes that pass a visual check but fail everywhere else

The most frequent failure is treating tagging as a one-time export setting rather than a document property that has to survive edits. A PDF exported correctly from a word processor, then annotated, redacted, or merged with another file using a tool that does not preserve structure, often loses its tags silently. The file looks identical. Nothing in the visual proof shows a problem. The first sign is usually a complaint, or a failed accessibility audit months later.

A second common mistake is tagging headings by appearance rather than by role. Bold, larger text used purely for visual emphasis inside a paragraph does not need a heading tag, and tagging it as one creates a false landmark that screen reader users will jump to expecting a new section, only to land mid-sentence. Heading tags should track document structure, not typography.

A third mistake specific to scanned documents is assuming that running OCR is the same as making a document accessible. OCR produces a text layer that can be selected and searched, which is necessary, but it does not produce a tag tree, reading order, or alt text on its own. A scanned, OCR'd PDF with no further remediation will often read as an unbroken wall of text with no headings at all, because the OCR engine had no way to know which lines were headings.

When this approach fails, and what to do instead

Manual remediation — going through a tag tree node by node — does not scale to a backlog of thousands of legacy documents, and organisations that try to brute-force it usually stall a few hundred files in. In that situation the realistic strategy is triage: identify which documents are actually being requested or actively used, remediate those first to full PDF/UA conformance, and for the long tail, provide an accessible HTML or plain-text alternative alongside the PDF rather than promising a remediation timeline nobody can meet.

Highly complex layouts — dense financial tables with merged headers spanning three levels, or scientific papers with inline mathematical notation — are also a case where full automated or semi-automated tagging genuinely struggles, and no current tool gets this reliably right without a human checking the association between header cells and data cells by hand. Budget real review time for these documents rather than trusting a single pass.

"Automated conformance checking tells you a document is not broken. It cannot tell you the document is good."

— Common refrain among accessibility auditors

A minimum viable accessibility checklist

• Document language is set at the file level, and any passages in a different language are tagged with that language locally.
• Every heading level is used in order, with no skipped levels, and headings describe what follows.
• Reading order matches visual order when the page is reflowed to a single column.
• Every meaningful image has alt text describing the information it conveys; decorative images are marked as artifacts.
• Tables have header cells associated with their data cells, with scope set for anything beyond a simple grid.
• Every form field has a programmatic label, and the tab order matches the visual order.
• The file has been run through an automated PDF/UA checker and any flagged issues have been resolved or consciously accepted with a reason recorded.

None of this requires exotic tooling. It requires treating the tag tree as part of the document, not as metadata you can regenerate later, and checking it every time the file changes hands between tools that might not preserve it.