PDF Accessibility Explained: Tags, Reading Order, and Alt Text

Key takeaways

• A PDF looking correct on screen says nothing about whether a screen reader can make sense of it — accessibility depends on a separate, invisible structure called the tag tree, not the visual layout.
• Reading order and visual layout aren't the same thing — a multi-column page can look right but read out of order if its tags don't match the sequence a person would actually read it in.
• Images and figures need alt text describing their content in words, since a screen reader has no way to interpret an image on its own.
• A scanned PDF is invisible to a screen reader until it's OCR'd, and even after OCR it usually still lacks the tags and reading order that make a document fully accessible — OCR is necessary but not sufficient.
• Full accessibility remediation — tagging, reading order, alt text at scale — generally needs a dedicated accessibility tool or checker, not just a general-purpose PDF editor.

A document can render pixel-perfect on your screen and still be unreadable to someone using a screen reader. Accessibility problems in a PDF live in a layer of the file that never shows up when you just look at the page, which is why a document can pass every visual check and still fail the one that actually matters to a blind or low-vision reader.

What makes a PDF accessible: the tag tree

Underneath the page content a PDF can render, the format also supports an optional structure tree — a hierarchy of tags marking which parts of the page are headings, paragraphs, lists, tables, or figures. It’s the same idea as semantic HTML: a screen reader doesn’t see a page of ink, it walks this structure and announces it piece by piece.

A PDF exported without tags — or a scanned page treated as one flat image — has none of this. A screen reader either has nothing to read at all or reads the entire page as one undifferentiated block, with no way to jump between headings, skip a table, or know where one paragraph ends and the next begins. Tags are invisible on the printed or on-screen page; two PDFs can look identical and one be fully navigable while the other is a wall of unstructured text to any assistive technology.

Reading order isn’t the same as visual layout

A PDF’s content is stored in whatever order it was drawn onto the page, and that internal order — not the visual layout — is what a screen reader follows by default. Simple single-column pages usually have content drawn in the same order they’re read, so this rarely causes problems.

Multi-column layouts, pull quotes, sidebars, and captions are a different story. These elements are often drawn interleaved with the main column rather than after it, so a screen reader can jump into the middle of a sidebar mid-sentence of the main text, then back out again — something no sighted reader would ever notice, because the visual layout still looks completely correct. Fixing this means editing the tag tree’s order directly, not the page’s appearance, which is why it’s easy to miss: nothing about looking at the rendered PDF tells you the reading order is wrong.

Alt text: describing what a screen reader can’t see

Images, charts, scanned signatures, and logos carry no inherent meaning a screen reader can extract — it can announce that an image exists, but not what’s in it, unless the image has alt text: a short, written description attached to it for exactly this purpose. A decorative flourish might reasonably get empty alt text so it’s skipped over; a chart carrying actual information needs its key takeaway summarized in words, since a screen reader can’t describe what a chart’s bars or lines show.

Missing alt text isn’t a rendering error — the page looks and prints exactly the same either way. It’s a gap that only shows up when the document is read aloud rather than looked at.

Scanned PDFs: OCR helps, but isn’t the whole fix

A scanned page — a photocopy, a faxed document, a phone photo saved as PDF — is a single image with no text underneath, which means a screen reader has nothing to read at all. OCR recognizes the text in that image and adds it back as a real, selectable text layer, which is the necessary first step toward making a scan accessible.

It’s rarely the whole fix, though. OCR output is usually one long, untagged block of recognized text — it doesn’t automatically reconstruct headings, reading order, or alt text for any images on the page. A scanned form that’s been OCR’d is a real improvement over an untouched scan, but it typically still needs tagging and structure added afterward before it reads the way a document authored directly in Word or Google Docs would.

Document title and language matter too

Two small metadata fields carry more weight for accessibility than their size suggests. A screen reader announces a document’s Title field when it opens the file — not the filename — so a PDF whose title metadata was never set often gets announced by whatever generic name the creating software assigned it, like a scanner’s default output name. Setting a clear, descriptive title is a small edit with an outsized effect on how the document introduces itself.

The Language field tells assistive technology which pronunciation and hyphenation rules to apply. A document tagged with the wrong language, or none at all, can get read aloud with the wrong accent and cadence even if every word is otherwise recognized correctly.

Accessible forms need labeled fields

A fillable PDF form field is just an empty box to a screen reader unless it carries a label or tooltip describing what it’s asking for. A sighted user infers a field’s purpose from the text printed next to it on the page; a screen reader only knows what’s attached to the field itself in the underlying form data, which is a separate piece of information from the visible label text sitting beside it.

Checking the work

Setting a document’s title, running OCR on a scan, and reviewing reading order by ear are all things a general-purpose PDF tool can help with. Verifying that an entire document’s tags, reading order, and alt text meet a formal standard is a more specialized job, usually handled by a dedicated accessibility checker — Adobe Acrobat’s built-in accessibility check and PAC (PDF Accessibility Checker) are two well-known tools built specifically for that audit, rather than for everyday PDF editing.

The technical standard behind all of this is PDF/UA (ISO 14289), the PDF-specific counterpart to the WCAG guidelines used for web accessibility more broadly. Many organizations — public-sector agencies especially — are required to meet an accessibility standard for the documents they publish, but exactly which standard applies, and what counts as compliant, varies by jurisdiction and by who’s publishing. Treat that as a question for whoever owns the compliance requirement, not something a PDF tool’s default settings decide for you.

Common questions about PDF accessibility

Does OCR-ing a scanned PDF make it accessible? It makes the text readable and searchable, which is a real improvement, but it doesn’t add tags, reading order, or alt text on its own — see the section above.

Is a tagged PDF the same as PDF/A? No. PDF/A is about long-term archival fidelity — locking in fonts and removing external references so a file renders identically decades from now. Tags are a separate structure aimed at making a document navigable by assistive technology. A file can be one, both, or neither.

Does adding alt text change how the page looks? No — alt text is attached to the image as invisible data, the same way a document’s metadata sits alongside the page content without altering it.

Do all PDF readers and screen readers support tags the same way? Most modern combinations (Acrobat Reader with NVDA, JAWS, or VoiceOver) support tag-based reading, but exactly how well a specific reader honors a specific tag varies, so testing with the assistive technology your actual audience uses is worth more than assuming compliance from the file alone.

Can I make a PDF reasonably accessible without paid software? The basics — a clear title, a correct language setting, OCR on any scans — are within reach of the same free, browser-based tools covered elsewhere on this blog. Full tagging and reading-order remediation across a long or complex document is where most free general-purpose tools run out of road.

Where this fits alongside everything else

Accessibility isn’t a single button next to compress or convert — it’s a handful of smaller habits spread across the tools you’re probably already using: setting a real title while you’re in there editing metadata, running OCR before a scan goes out the door, and taking a second look at reading order on anything with columns or sidebars. PDFPilot keeps those pieces one click from whatever PDF is already open, so the parts of accessibility a lightweight tool can actually handle don’t get skipped simply because the fix lived in a different tab.