What a screen reader sees in your PDF

A screen reader (software that speaks the screen aloud) reads a PDF one piece at a time, in whatever order it can work out. For someone using one, that is the document. Whether it comes through as a document, as word soup, or as silence depends on decisions the publisher made, mostly without knowing they were making them.

Three kinds of PDF, and what each gives a screen reader

Scanned PDFs: no text at all

A scan contains photographs of pages, with pixels where a digital file would have characters. A screen reader finds no text and announces something like "blank document", which is how a 40-page report can be published, downloaded and read by thousands while being literally empty for part of its audience. The first-aid fix is OCR: recognising the pixels and writing a real text layer behind the image gives assistive tech words to speak. OCR restores the text but not the structure, and it is still the biggest single improvement available.

Untagged PDFs: text in a guessed order

Most digitally-made PDFs store glyphs at coordinates with no record of reading order or structure. Assistive software must reconstruct the document from geometry, with the same guesswork and the same failures as copying text out of a PDF. Two columns interleave into nonsense, a table becomes a stream of cell contents with no rows, and headings are indistinguishable from sentences, so there's no skimming and no "jump to next section"; the reader gets the fire-hose, start to finish. Images are silent unless someone wrote a description. The document technically has all its words, but it is exhausting or impossible to use.

Tagged PDFs: structure a reader can navigate

Since 2001 the format has supported an optional structure layer, called tags, recording that this line is a first-level heading, this text is a paragraph, this is a table with these rows, this image means photo of the north elevation, read things in this order. With tags present, a screen reader user navigates the way sighted readers skim: heading to heading, past the boilerplate, straight to the table. The formal version of "tagged and done right" is PDF/UA, the accessibility profile of the standard.

Why most PDFs are the middle kind

It's a matter of defaults. Tags exist only if the exporting application writes them, and the export paths people actually use often don't. The path that catches everyone is printing to PDF. The print pipeline produces exactly what a printer needs, ink positions, and throws away everything a screen reader needs; a document "printed" to PDF is untagged every time, even from Word. The same document exported from Word with its accessibility options on comes out tagged, with the heading structure carried over from the styles. The content and the look are identical; the experience for part of the audience is decided by which menu item the author clicked.

Increasingly it's also decided by law. The US has required accessible documents from federal bodies under Section 508 for years. The EU's Web Accessibility Directive covers documents published by the public sector, and the European Accessibility Act has extended obligations to specified private-sector products and services (e-commerce, e-books, consumer banking, transport) since June 2025.

What to check before you publish

For documents you publish, most of the work happens at export and costs minutes. Write with real heading styles rather than big bold text, so the exporter has structure to record. Give meaningful images a description and mark decorative ones as decorative. Export, don't print, and tick the "tagged PDF" or accessibility option if your application shows one. Set the document title and language. Then do the ten-second smoke test: try to select the text (if you can't, you shipped a scan), and copy a paragraph out to see whether it emerges in a sane order. For a proper audit, use a real screen reader: NVDA is free on Windows, and VoiceOver is built into every Mac. Real assistive technology catches problems automated checkers miss.

For documents you receive, the repairs are rougher but real. OCR the scans. For a document needed as reading material rather than as a fixed page, converting to HTML or Word can help, because the conversion's reconstructed structure of real headings and real paragraphs is the same structure assistive tech wants, and HTML in a browser is a far more accessible reading surface than an untagged PDF. And plain text extraction is the blunt fallback that at least puts the words where any tool can reach them.

What the tools on this site don't do

The tools here don't author tags; tagging is authoring work that belongs in the source document. Some operations also cost accessibility, for reasons their pages state: redaction rebuilds the pages you mark as images, because that's what makes removal certain, and Extreme compression rasterises text to hit brutal size targets. Both trade the text layer away. When a document has an audience using assistive tech, make that trade consciously, or run OCR afterwards to give the rebuilt pages their words back.