A PDF that looks perfectly normal on screen can be completely unusable for someone using a screen reader, and the gap between those two experiences comes down almost entirely to one thing: tagging. Tags are an invisible structural layer inside a PDF, a hidden outline stating what each piece of visible content actually is. The accessible PDF checklist above turns that layer into something a person can verify item by item; this lesson covers why each item on it exists.
Why an accessible PDF checklist exists at all
A sighted reader scanning a page uses visual cues automatically: a bigger, bolder line is a heading, indentation signals a list, a grid of boxes is a table. A screen reader has no access to any of that visual information. It relies entirely on tags, a parallel layer of metadata stating explicitly that this text is a heading, that this group of items is a list, that this box is a table cell belonging to a specific row and column. Without tags, a PDF’s visible layout and its actual accessible structure can be completely disconnected: a document can look flawlessly organized and still read to a screen reader as one long, undifferentiated stream of text, in whatever order the content happens to be stored internally, not necessarily the order it appears on the page.
The standards behind a tagged PDF
None of this is informal best practice invented by accessibility advocates on their own initiative; there is a real technical standard behind it. PDF/UA, PDF Universal Accessibility, is formally ISO 14289, first published in 2012 and updated in 2014, and it specifies in detail what a fully accessible PDF has to contain: complete tagging of real content in logical reading order, semantically correct tags for headings, lists and tables, alternative text for graphics, and fonts properly mapped to readable characters. PDF/UA sits alongside the Web Content Accessibility Guidelines, now at version 2.2 as of October 2023, which set the underlying success criteria most accessibility law and regulation ultimately points back to, for web pages and documents alike.
Two legal frameworks translate those guidelines into enforceable requirements. In the United States, Section 508 requires federal agencies’ digital content to meet WCAG 2.0 Level AA, following a 2017 refresh that explicitly harmonized US federal rules with the international WCAG benchmark. In the European Union, EN 301 549 plays a broadly similar role for public sector digital content, incorporating WCAG as its baseline and extending coverage to non-web documents and software more generally. A tagged, PDF/UA-conformant document is built to satisfy both frameworks at once, since all three standards ultimately trace back to the same underlying WCAG success criteria.
How to make a PDF accessible: what actually needs to happen
Making a PDF accessible starts well before the export step. A source document with real heading styles applied, rather than large bold text formatted to merely look like a heading, exports with proper heading tags automatically in most modern software. Images need alternative text written at the point of insertion, stating what the image actually communicates rather than a generic placeholder. Tables need real header rows and columns marked as such, not just visually bold or shaded to resemble headers. And once exported, the tag tree and the reading order both need a manual check, since automated exports frequently get the reading order wrong around multi-column layouts, pull quotes, and sidebars, elements a sighted reader navigates intuitively but a screen reader has to be told about explicitly.
How to test whether a PDF actually works for a screen reader
Testing does not require guessing. PAC, a free downloadable tool, checks a file directly against the PDF/UA standard and reports specifically what fails and why, functioning as the closest thing to an authoritative pass or fail available without paid software. Adobe Acrobat’s built-in accessibility checker runs many of the same structural checks from inside the same program many documents are already built or reviewed in, useful as a first pass before a file leaves the building. Neither tool replaces the third check: running an actual screen reader over the finished document, listening to how it announces headings, tables and links in sequence. Some problems, an oddly ordered reading sequence, a table read in a confusing order, only become obvious by ear, in a way no automated checker fully catches.
The most common failures
By a wide margin, the most common failure is the simplest one: a PDF exported straight from a page layout or presentation program with no accessibility pass applied at all. It looks completely normal on screen and reads as an undifferentiated block of noise to anyone using assistive technology, since none of the underlying structure a screen reader depends on was ever generated in the first place. Close behind that: images with no alternative text, or with alt text that just repeats the word “image” or the file name; tables built from manually spaced text rather than a real table structure, which a screen reader cannot parse as rows and columns at all; and a document with no title set in its properties, so a screen reader announces the raw file name instead of a meaningful document title. Each of those failures is invisible on screen and immediately obvious the moment a real screen reader opens the file, which is exactly the gap an accessible PDF checklist, and the standards behind it, exist to close before a document ever reaches a reader who depends on it.
Document accessibility is really one layer on top of the broader document design and readability covered elsewhere in this section: contrast, repetition, alignment and proximity make a document easier for anyone to read, while tagging makes the same document usable by someone who cannot see the layout those four principles create at all. Checking a PDF’s structure this closely is itself a form of the reading skill covered in how to read a report: a document’s format is part of what determines whether its content ever actually reaches a reader in the first place.