Tagged PDF and Accessibility: How to Make a PDF Screen Readers Can Use

Tagging arrived in PDF 1.4. It adds a logical structure tree that is separate from how the page looks. The tree starts at the document's StructTreeRoot, and each element has a standard type: H1 to 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 lets a screen reader announce 'heading level 2' or 'list, 5 items', and lets users jump from heading to heading instead of hearing every word. It also drives reflow on small screens and export to HTML or Word.

Tags are invisible on the page. A document can look perfect and have no tags at all. Most PDFs from scanners, screenshots and older export tools start out that way.

Sighted readers scan a page by position, jumping between columns, sidebars and captions. A screen reader follows the structure tree, one element after another. If the tag order doesn't match the intended reading order, content is read out in a confusing sequence, even when the page looks right.

Multi-column layouts are the classic failure. Text gets read straight across both columns instead of down one and then the other. Pull quotes, footnotes, running headers and captions also often land in the wrong place.

To fix reading order, you reorder the tags, not the visible content. Check the order in a tags or order panel, then listen to it with a screen reader. Things that sit close together on the page aren't always read in sequence.

Every meaningful image needs alternate text, the /Alt entry on a Figure tag. Say what the image communicates, not that it is an image. Alt text for a chart should give the trend or key number, not just 'chart'.

Mark content that carries no information as an artifact so screen readers skip it. That includes decorative borders, background watermarks, page numbers and repeated header or footer graphics. Removing this noise matters as much as tagging real content.

Set the document language (the /Lang entry) and mark any passages in another language, so the screen reader pronounces words correctly. Also give the file a clear title in its metadata, which viewers show instead of the file name.

PDF/UA (ISO 14289-1) is the technical standard for accessible PDF. It sets out how tags, artifacts, metadata and structure must work. PDF/UA-2 (ISO 14289-2, published 2024) extends it to PDF 2.0. The Matterhorn Protocol breaks PDF/UA into 31 checkpoints and 136 failure conditions that testing tools use.

WCAG is the broader standard for all digital content. The W3C published WCAG 2.1 in 2018 and WCAG 2.2 in 2023. It rests on four principles (perceivable, operable, understandable, robust) and has three levels, A, AA and AAA. Most laws target level AA. PDF/UA and WCAG overlap a lot, so a PDF that meets PDF/UA meets most WCAG criteria that apply to PDFs.

In the US, Section 508 of the Rehabilitation Act requires federal agencies to make electronic documents accessible and adopts WCAG 2.0 level AA by reference. The ADA covers the private sector, 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, sets similar requirements. Legal risk aside, accessible files work for more people.

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't be made accessible. Source files that use real heading styles in Word, InDesign or similar export much cleaner tags than you can fix by hand later.

Automated checkers catch the mechanical errors. Acrobat Pro's Accessibility Check (Full Check) and the free PDF Accessibility Checker (PAC) test against PDF/UA and flag missing tags, missing alt text and reading order problems. They can't judge whether alt text makes sense or whether the order is logical, so a person still has to review.

The final test is listening. Open the document in a screen reader and move by headings, links, lists and tables. NVDA (free) and JAWS on Windows and VoiceOver on macOS and iOS each handle PDFs a little differently, so test in more than one.

Form fields must be tagged and labeled. Each field needs a tooltip (the TU entry) that names its purpose, because that is what the screen reader reads out. Tab order must follow the structure so keyboard users move through fields in a sensible order. Required fields and error messages must be exposed to assistive technology, not shown only by color or position.

Data tables are the other common problem. Header cells must be tagged TH, not TD, and each needs a Scope of Row or Column so every data cell links to the right headers. Tables with merged or multi-level headers may need explicit Headers and ID links.

Don't use tables just for layout. If there is no real row-and-column relationship, structure the content another way. In a real data table, correct headers let a screen reader say 'Revenue, Q3: 1.2 million' instead of a bare number.