How does a screen reader actually read a PDF?

Not the way you read it visually — it reads the document’s underlying structure, called the tag tree, in order. A screen reader cannot interpret the visual layout on the page; it relies on tags that label each piece of content (this is a heading, this a paragraph, this a list, this a table) and on a defined reading order that says what comes after what. From those, it speaks the content and lets the user navigate by element — jump heading to heading, skim a list, enter a table. If the PDF has no tags, the screen reader has only a guess at the order and no idea what anything is, so it reads a flat, structureless stream. And if the PDF is a scan with no real text, there is literally nothing for it to read. Accessibility for screen readers is therefore mostly about giving the document genuine text and a correct tag structure.

What makes a PDF actually accessible to a blind user?

A combination of real text, correct tags, sensible reading order, described images, structured tables, and labelled form fields — the things a sighted reader gets from layout, supplied explicitly for someone who cannot see it. Concretely: the document must have a genuine text layer (so scans need OCR first); headings, paragraphs, and lists must be tagged as what they are so the user can navigate and understand structure; the reading order must follow the logical flow, not the visual position, so multi-column pages do not read scrambled; every meaningful image needs alt text describing it; tables need their header cells and row/column relationships marked so data is intelligible; and form fields need accessible names so the user knows what each one is for. The PDF/UA standard codifies these requirements. Hit them and a blind user can read and navigate the document as a real document, not a wall of text.

Why does reading order matter so much?

Because a screen reader speaks content in the order the tag tree specifies, and if that order does not match the logical flow, the document becomes confusing or nonsensical even when every word is present. The classic failure is a multi-column page: visually you read down column one then column two, but if the reading order runs across the page, the screen reader interleaves the columns into gibberish. Sidebars, captions, headers, and footers dropped into the wrong place in the order have the same effect — a caption read in the middle of a sentence, a page number announced between paragraphs. Setting a correct reading order is one of the highest-impact accessibility fixes, because it is the difference between a document that reads as a coherent narrative and one that is technically "all there" but impossible to follow by ear.

Do all images need alt text?

Meaningful images need descriptive alt text; purely decorative ones should be marked as decorative so the screen reader skips them. The distinction matters: a chart, a photo that carries information, a diagram, or a logo that conveys identity needs a concise text description so the blind user gets the same information a sighted reader does from seeing it. A decorative flourish, a background texture, or a spacer image carries no information and should be tagged as an artifact/decorative so it is not announced — otherwise the user hears pointless interruptions. Good alt text describes the image’s purpose and content succinctly, not "image of" boilerplate, and for complex visuals like detailed charts you may need a longer description or an accessible data table nearby. The goal is parity of information, not narrating every pixel.

How do I actually test that a PDF works with a screen reader?

Run an automated checker for the obvious gaps, then test with a real screen reader, because the two catch different things. Automated accessibility checkers (including a PDF/UA or built-in checker) flag missing tags, missing alt text, and structural problems quickly and are a good first pass — but they cannot judge whether your reading order makes sense or whether your alt text is actually meaningful. For that you need to listen: open the PDF in a screen reader (NVDA on Windows and VoiceOver on Mac are widely available) and navigate it by heading, read it top to bottom, tab through any form, and hear whether it is coherent. Most real accessibility problems — scrambled order, useless alt text, unlabelled fields — only become obvious when you experience the document by ear, which is exactly how your blind users will.

Is it safe to remediate PDFs with an online tool?

Use a tool that runs on your own device for non-public documents. Accessibility remediation often happens on reports, forms, and publications that may be confidential before release, and many online tools upload your file to a third-party server. Client-side (in-browser) tools — for example OCR to give a scan a text layer, the prerequisite for any screen-reader access — process locally so the file never leaves your computer, and ScoutMyTool’s PDF tools work this way. For confidential documents, confirm a tool is client-side before uploading, or use offline software. Making a document accessible should not require exposing it to an extra server along the way.

7 min read

PDF accessibility — making PDFs work for screen readers

By ScoutMyTool Editorial Team · Last updated: 2026-05-21

The first time I listened to one of my own PDFs through a screen reader, it was a humbling few minutes: the document I thought was perfectly clear came out as a flat stream with no headings, an image announced as nothing, and a two-column page read straight across into nonsense. A screen reader does not see the page you designed — it follows the document’s tags, reading order, and alt text, and if those are missing or wrong, a blind user gets confusion or silence. This guide is about that reader’s actual experience: what makes a PDF genuinely accessible to someone using a screen reader, why each piece matters, and — the step most people skip — how to test it by listening, not just by running a checker.

What a screen reader needs — and what happens without it

Element	What it needs	If it is missing
Real text (not a scan)	A genuine text layer (OCR a scan)	Screen reader reads nothing at all
Tags / structure	Tagged headings, paragraphs, lists	Content read as one undifferentiated blob
Reading order	Logical order set in the tag tree	Columns/sidebars read out of sequence
Image alt text	A text description on each meaningful image	Image announced as nothing, or skipped
Table structure	Header cells marked; row/column associations	Cells read as a flat, meaningless stream
Form field labels	Each field has an accessible name	User hears "edit text" with no idea what to enter

Step by step — make a PDF screen-reader friendly

Ensure real text exists. If the PDF is a scan, OCR it first — a screen reader cannot read images of text, so this is the precondition for everything else.
Tag the structure. Mark headings, paragraphs, lists, and tables as what they are so the reader can announce and navigate them.
Set a logical reading order. Order the tags to follow the content’s flow (not the visual position), so multi-column and complex pages read coherently.
Describe images, mark decorative ones. Add concise alt text to meaningful images; flag purely decorative ones so they are skipped.
Make tables and forms intelligible. Mark table header cells and relationships, and give every form field an accessible name.
Check, then listen. Run an accessibility/PDF-UA checker for the obvious gaps, then test with a real screen reader (NVDA, VoiceOver) to catch order and alt-text problems a checker cannot judge.

The principle: structure is the accessibility

For a screen reader, the accessibility of a PDF essentially is its structure — the genuine text plus the tag tree, reading order, alt text, and labels that tell the reader what everything is and in what order. Visual design, which carries all the meaning for a sighted reader, conveys nothing to someone listening; that meaning has to be encoded into the structure instead. This is also why building accessibly from the start (authoring with real heading styles and adding alt text as you go) is far easier than remediating a finished, untagged file afterward. And it is why testing must include listening: an automated checker confirms the tags exist, but only a real screen reader reveals whether the document actually makes sense by ear. Get the structure right and test it the way your users will, and a PDF stops being a barrier and becomes a document everyone can read.

FAQ

How does a screen reader actually read a PDF?: Not the way you read it visually — it reads the document’s underlying structure, called the tag tree, in order. A screen reader cannot interpret the visual layout on the page; it relies on tags that label each piece of content (this is a heading, this a paragraph, this a list, this a table) and on a defined reading order that says what comes after what. From those, it speaks the content and lets the user navigate by element — jump heading to heading, skim a list, enter a table. If the PDF has no tags, the screen reader has only a guess at the order and no idea what anything is, so it reads a flat, structureless stream. And if the PDF is a scan with no real text, there is literally nothing for it to read. Accessibility for screen readers is therefore mostly about giving the document genuine text and a correct tag structure.
What makes a PDF actually accessible to a blind user?: A combination of real text, correct tags, sensible reading order, described images, structured tables, and labelled form fields — the things a sighted reader gets from layout, supplied explicitly for someone who cannot see it. Concretely: the document must have a genuine text layer (so scans need OCR first); headings, paragraphs, and lists must be tagged as what they are so the user can navigate and understand structure; the reading order must follow the logical flow, not the visual position, so multi-column pages do not read scrambled; every meaningful image needs alt text describing it; tables need their header cells and row/column relationships marked so data is intelligible; and form fields need accessible names so the user knows what each one is for. The PDF/UA standard codifies these requirements. Hit them and a blind user can read and navigate the document as a real document, not a wall of text.
Why does reading order matter so much?: Because a screen reader speaks content in the order the tag tree specifies, and if that order does not match the logical flow, the document becomes confusing or nonsensical even when every word is present. The classic failure is a multi-column page: visually you read down column one then column two, but if the reading order runs across the page, the screen reader interleaves the columns into gibberish. Sidebars, captions, headers, and footers dropped into the wrong place in the order have the same effect — a caption read in the middle of a sentence, a page number announced between paragraphs. Setting a correct reading order is one of the highest-impact accessibility fixes, because it is the difference between a document that reads as a coherent narrative and one that is technically "all there" but impossible to follow by ear.
Do all images need alt text?: Meaningful images need descriptive alt text; purely decorative ones should be marked as decorative so the screen reader skips them. The distinction matters: a chart, a photo that carries information, a diagram, or a logo that conveys identity needs a concise text description so the blind user gets the same information a sighted reader does from seeing it. A decorative flourish, a background texture, or a spacer image carries no information and should be tagged as an artifact/decorative so it is not announced — otherwise the user hears pointless interruptions. Good alt text describes the image’s purpose and content succinctly, not "image of" boilerplate, and for complex visuals like detailed charts you may need a longer description or an accessible data table nearby. The goal is parity of information, not narrating every pixel.
How do I actually test that a PDF works with a screen reader?: Run an automated checker for the obvious gaps, then test with a real screen reader, because the two catch different things. Automated accessibility checkers (including a PDF/UA or built-in checker) flag missing tags, missing alt text, and structural problems quickly and are a good first pass — but they cannot judge whether your reading order makes sense or whether your alt text is actually meaningful. For that you need to listen: open the PDF in a screen reader (NVDA on Windows and VoiceOver on Mac are widely available) and navigate it by heading, read it top to bottom, tab through any form, and hear whether it is coherent. Most real accessibility problems — scrambled order, useless alt text, unlabelled fields — only become obvious when you experience the document by ear, which is exactly how your blind users will.
Is it safe to remediate PDFs with an online tool?: Use a tool that runs on your own device for non-public documents. Accessibility remediation often happens on reports, forms, and publications that may be confidential before release, and many online tools upload your file to a third-party server. Client-side (in-browser) tools — for example OCR to give a scan a text layer, the prerequisite for any screen-reader access — process locally so the file never leaves your computer, and ScoutMyTool’s PDF tools work this way. For confidential documents, confirm a tool is client-side before uploading, or use offline software. Making a document accessible should not require exposing it to an extra server along the way.

Citations

Give a scan real text — in your browser

A scanned PDF is invisible to screen readers until it has a text layer. Add one with ScoutMyTool OCR — client-side, so the document never leaves your computer — as the first step toward accessibility.

Open the OCR tool →