Accessible PDFs: The Report Nobody Can Read

Companies that would never ship an inaccessible web page ship inaccessible PDFs every week without thinking about it. The annual report, the price list, the product spec sheet, the application form, the menu. Someone finishes the document in a design tool or a word processor, exports it, uploads it, and moves on. The web page linking to it gets reviewed, tested, maybe even audited. The PDF itself is treated as a kind of freight: a sealed box the website merely delivers. Nobody opens the box to check whether anyone can actually read what’s inside.

Here is what’s inside, more often than not. A PDF is fundamentally a description of where ink goes on a page. In its rawest form it says: place these glyphs at these coordinates, draw this line here, put this image there. That’s enough for printing, which is what the format was born for. It is not enough for a screen reader, which needs to know what things are, not just where they are. Which glyphs form a heading? In what order should the text be read when the layout is two columns? Is this rectangle of pixels a decorative flourish or a chart carrying half the document’s meaning? Is this grid of lines a table, and if so, which cell belongs to which header? The ink doesn’t say.

The PDF format actually has an answer to this, and it’s called tagging. A tagged PDF carries a hidden structural layer, much like HTML, that marks passages as headings, paragraphs, lists, and tables, records a reading order, and holds text alternatives for images. When the tags are present and correct, a screen reader can handle a PDF respectably. The problem is that tags don’t happen by accident. Some export paths produce them if the source document was structured properly, meaning real heading styles rather than bold enlarged text, real table objects rather than drawn lines. Many export paths produce no tags, or mangled ones. And the worst case, still remarkably common, is the scanned PDF: a photograph of paper, containing no text at all. To a screen reader, a scanned PDF is a stack of blank pages. The user opens your two-hundred-page report and hears nothing.

What I find interesting about this problem is why it persists on sites that otherwise care. I think it’s because the PDF sits just outside everyone’s job. The web team’s tooling stops at the upload. The automated accessibility scanner checks the pages and typically doesn’t open the documents. The person who wrote the PDF used a tool that gave them no signal either way. So the least accessible content on the site is precisely the content that no process examines, and it’s often the highest-stakes content too. Think about what ends up in PDFs: contracts, benefits information, government forms, financial statements, instructions. The documents where being unable to read them costs the reader the most.

The fix comes in two forms, and the first one is underrated: don’t make a PDF. Ask, for each document, why it isn’t a web page. Sometimes there’s a genuine answer, like a legal requirement for a fixed-layout document, or a form that must be printed and signed. But most of the time the honest answer is that a PDF was easier for the author, and that’s a bad trade, because HTML is better for the reader in nearly every way. It reflows on phones instead of forcing pinch-and-zoom on a fixed page. It inherits the accessibility work you’ve already done on your site. It’s searchable, linkable to a specific section, and indexed properly by search engines instead of ranking as an opaque blob. Every time I’ve seen a team convert a PDF-based process to plain web pages, the pages got more use than the PDF ever did, from everyone, not just from assistive technology users. That’s the usual shape of accessibility work: the ramp gets used by the strollers and the delivery carts too.

When the document genuinely must be a PDF, the work is to make it a properly tagged one, and the leverage is almost all in the source document rather than in after-the-fact repair. Use real heading styles so the exporter can emit heading tags. Use real tables. Write alt text for images where you author them. Set the document language and a title. Then export through a path that preserves tags, and test the result the same way you’d test a page: open it with a screen reader and listen to whether the reading order makes sense. Remediating an untagged PDF after the fact is possible but miserable, page by page, and the next export overwrites your work. Fixing the source fixes every future version.

And if you do nothing else, do this: never publish a scanned image of text when you have the original file. The gap between a scan and a tagged export is the difference between a document nobody using a screen reader can read and one almost everybody can.

I started paying attention to this while building GazeSite, because auditing a site’s pages and ignoring its documents felt like inspecting a restaurant’s dining room and skipping the kitchen. The pattern I keep seeing is the same: the site is fine, and the substance lives in files nobody has ever tested. Open the boxes you’re shipping. Some of them have been empty for years.