Tagged PDF and Accessibility: How to Make PDFs Usable for Everyone

Introduced in PDF 1.4, tagging adds a logical structure tree to a document, separate from how the page looks. The tree is a hierarchy of structure elements rooted in the document's StructTreeRoot, and each element maps to a standard type: H1 through H6 for headings, P for paragraphs, L, LI, and LBody for lists, Table, TR, TH, and TD for tables, and Figure for images.

This structure is what lets a screen reader announce "heading level 2" or "list, 5 items," and what lets users jump between headings instead of reading every word in sequence. It also drives reflow on small screens and export to accessible formats like HTML or Word.

Critically, tags are invisible on the page. A document can look perfectly formatted and still be completely untagged, which is the default state of most PDFs produced by scanners, screenshots, or older export tools.

Sighted readers scan a page spatially, jumping between columns, sidebars, and captions. A screen reader instead follows the sequence of the structure tree, one element after another. If that tag order does not match the intended reading order, content is announced in a confusing, sometimes nonsensical sequence, even when the page looks correct.

Multi-column layouts are the classic failure: text can be read straight across both columns instead of down one and then the next. Pull quotes, footnotes, running headers, and figure captions also commonly land in the wrong place.

Fixing reading order means arranging the tags in logical order, not moving anything visually. In practice you verify order in a tag or order panel and confirm it by listening with an actual screen reader, since visual proximity is no guarantee of correct sequence.

Every meaningful image needs alternate text (the /Alt entry on a Figure tag) that conveys its purpose or content concisely. Describe what the image communicates, not that it is an image; a chart's alt text should summarize the trend or key data point, not just say "chart."

Content that carries no information, such as decorative borders, background watermarks, page numbers, and repeated header or footer graphics, should be marked as an artifact so screen readers skip it entirely. Marking decoration as an artifact matters as much as tagging real content, because it removes noise.

Finally, set the document's default language (the /Lang entry) and mark any passages in a different language so the screen reader uses correct pronunciation. A meaningful document title in the metadata, shown instead of the file name, rounds out the basics.

PDF/UA (ISO 14289-1) is the technical standard specifically for accessible PDF, defining exactly how tags, artifacts, metadata, and structure must be implemented; PDF/UA-2 (ISO 14289-2, published 2024) extends it to PDF 2.0. The companion Matterhorn Protocol breaks PDF/UA into 31 checkpoints and 136 failure conditions that tools use to test conformance.

WCAG is the broader, technology-neutral standard, with WCAG 2.1 published by the W3C in 2018 and WCAG 2.2 in 2023. It is organized around four principles, Perceivable, Operable, Understandable, and Robust, with conformance levels A, AA, and AAA. Most laws target Level AA. PDF/UA and WCAG overlap heavily, so meeting PDF/UA satisfies most PDF-relevant WCAG criteria.

In the United States, Section 508 of the Rehabilitation Act requires federal agencies to make electronic documents accessible and incorporates WCAG 2.0 Level AA by reference. The ADA drives private-sector obligations, and a 2024 Department of Justice rule requires state and local governments to meet WCAG 2.1 AA for web content and mobile apps. In the EU, the EN 301 549 standard (which references WCAG) underpins comparable requirements. Beyond legal exposure, accessible documents are simply usable by more people, which is the ethical baseline.

Start from a good source. If the PDF is a scan, run OCR first so there is real text to tag; an image-only page can never be made accessible on its own. Well-structured source files, using real heading styles in Word, InDesign, or similar, export far cleaner tags than manual fixes can produce later.

Automated checkers catch the mechanical failures: Acrobat Pro's Accessibility Check (Full Check) and the free PDF Accessibility Checker (PAC) both test against PDF/UA and flag missing tags, missing alt text, and reading-order problems. Automation cannot judge whether alt text is meaningful or whether reading order makes sense, so manual review is always required.

The definitive test is listening. Run the document through a real screen reader and navigate by headings, links, lists, and tables. NVDA (free) and JAWS on Windows, and VoiceOver on macOS and iOS, each expose PDFs slightly differently, so testing in more than one is wise.

Interactive forms must have tagged, labeled fields. Each field needs a tooltip (the TU entry) that names its purpose, because that label is what the screen reader announces. Tab order must follow the logical structure so keyboard users move through fields in a sensible sequence, and required fields and error messages should be programmatically indicated.

Data tables are the other frequent trouble spot. Header cells must be tagged as TH rather than TD, and each header cell should carry a Scope (Row or Column) so assistive technology can associate every data cell with the right headers. Complex tables with merged or multi-level headers may need explicit Headers/ID associations.

Avoid using tables purely for visual layout; if a table has no real row-and-column relationships, structure the content another way. When a data table is genuine, correct header tagging is what lets a screen reader announce "Revenue, Q3: 1.2 million" instead of a bare, contextless number.