What is a "tagged PDF" and why does it matter?

A tagged PDF has a structure tree — a hierarchical map from page content (text runs, images, table cells, list items) to semantic roles (heading, paragraph, figure, table, list). Screen readers (JAWS, NVDA, VoiceOver, Narrator) walk this tree to announce the document in a meaningful order — "Heading 1: Annual Report", then "Section 2: Financial Overview", then the figure caption and the table rows. An untagged PDF is a flat positional dump of glyphs; the screen reader has nothing to navigate by, and the user experience is roughly equivalent to listening to a randomised list of words. Tagged PDFs are mandatory for PDF/UA-1 and effectively required for WCAG 2.1 AA compliance.

How do I make a tagged PDF from a Word document?

Use Word's built-in PDF exporter (Save As → PDF) and tick "Document structure tags for accessibility" in the Options dialog. The export uses your Heading 1 / Heading 2 / Heading 3 styles to build the tag tree — so the most important upstream step is to use proper heading styles in Word, not just bigger fonts. The same applies to Google Docs (File → Download → PDF; preserves tags by default) and LibreOffice Writer (Export as PDF → "Tagged PDF" checkbox). If your source document does not use heading styles, no tagged output is possible regardless of the export tool.

My PDF is already published — can I add accessibility tags after the fact?

Yes, but it is more work than tagging at export time. Adobe Acrobat Pro has an "Auto-Tag" feature plus a manual Tags panel for fixing what auto-tagging misses; this is the most thorough path but requires the paid Acrobat Pro. Free alternatives: re-export from the source document with proper heading styles, or use a tagging tool like axesPDF, Pave PDF, or the open-source Pdfsam Enhanced. ScoutMyTool's tagged-PDF validator reports what is missing so you know what to fix, but does not currently retag automatically.

How do I check whether my PDF is actually accessible?

Run it through a validator. The free ones: PAC 2024 (PDF Accessibility Checker, by Access for All) runs as a Windows desktop app and produces a detailed report; axesPDF QuickFix is a free web tool from axes4 GmbH; ScoutMyTool's Tagged PDF Validator runs in your browser. For Section 508 / WCAG compliance audits, Adobe Acrobat Pro's Accessibility Check is the closest thing to an official tool. None of the automated checkers catches everything — final accessibility always requires human review (especially of alt text quality and reading order).

What is the difference between "alt text" and "actual text" in a PDF?

Alt text describes what an image conveys for screen-reader users — e.g., "Bar chart showing Q3 revenue of $1.2M, up 15% year-over-year". It is set on Figure tags. Actual Text is a related attribute that provides the textual equivalent of content that is rendered as something other than text — for example, a logo rendered as a vector graphic whose actual text content is "Acme Inc.". Most simple cases need only alt text; Actual Text becomes relevant when the visual rendering is fundamentally a glyph (a hand-drawn signature, a stylised logo) and the screen reader needs to know the underlying word.

Do scanned PDFs need OCR before they can be accessible?

Yes, absolutely. An image-only scanned PDF contains zero text — the page is a photograph of a document. Screen readers find nothing to announce. Run the scan through OCR (Adobe Acrobat Pro's OCR, ocrmypdf on Linux, Tesseract via a wrapper, or any cloud OCR service) to add a text layer beneath the image. Then tag the result. The OCR text layer is what every accessibility validator and screen reader will consume. Without OCR, a scanned PDF is fundamentally inaccessible no matter how well-tagged it is.

What are the legal consequences of shipping an inaccessible PDF?

It depends on jurisdiction and sector. US federal agencies are bound by Section 508 of the Rehabilitation Act and can face procurement complaints and civil enforcement; federal contractors may have contracts cancelled. US private businesses serving the public are subject to ADA Title III lawsuits — case law (Robles v. Domino's and others) has applied the ADA to digital content including PDFs. In the EU, public-sector bodies are subject to Directive 2016/2102 and the European Accessibility Act extends accessibility obligations to most consumer-facing businesses from June 2025. The financial exposure is real, and the cost of building accessible PDFs from the start is far lower than retrofitting after a complaint.

PDF accessibility — make documents screen-reader friendly (2026)

12 min read

PDF accessibility — make documents screen-reader friendly (2026)

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

A colleague who is legally blind once told me his rule for handling new PDFs: "I open it with my screen reader. If the first thirty seconds are intelligible, I keep reading. If they are word-soup, I delete the file and email the sender." He said this gently, like someone explaining a routine inconvenience, but it landed. The PDFs I had been producing — exported from Word with no heading styles, scanned without OCR, images with no alt text — were almost all word-soup. This article is the practical playbook for shipping PDFs that the next reader can actually use, whether they read with eyes or with assistive technology, and the standards (PDF/UA-1, WCAG 2.1, Section 508, EAA) that govern compliance.

The accessibility standards that apply to PDFs

Five standards intersect in the PDF accessibility space. Knowing which one applies to your situation tells you what you actually need to do.

Standard	Scope	Legal force	Notes
PDF/UA-1 (ISO 14289-1:2014)	Specifically PDFs	Industry standard referenced by other regulations	The dedicated PDF-accessibility ISO standard. Defines required structure (tagging, alt text, reading order, language) and forbidden constructs (artifacts not marked as decorative, untagged content).
WCAG 2.1 (W3C)	Web content in general, including PDFs delivered via web	Referenced by Section 508 and EN 301 549	The dominant accessibility standard. PDFs published online are expected to meet WCAG 2.1 AA (the practical compliance bar). Specific PDF techniques are documented in WCAG's PDF Techniques annex.
Section 508 (29 U.S.C. § 794d)	US federal agencies and federal contractors	Statutory — federal procurement and federal-funded ICT must comply	36 CFR Part 1194 (the Section 508 ICT Refresh, 2018) requires PDFs produced by federal agencies to meet WCAG 2.0 AA, which in practice means PDF/UA-equivalent tagging.
EN 301 549 (EU)	EU public-sector websites and apps; private-sector under the European Accessibility Act	Statutory in EU member states (Directive 2016/2102 + EAA Directive 2019/882)	EN 301 549 references WCAG 2.1 AA. The European Accessibility Act extends accessibility requirements to many private-sector services from 28 June 2025.
ADA Title III (US, private sector)	US private businesses serving the public ("places of public accommodation")	Statutory; case law (Robles v. Domino's) has applied to digital content	No specific technical standard cited in the statute, but courts typically reference WCAG 2.1 AA as the de-facto compliance bar.

For practical purposes in 2026, "accessible PDF" means a tagged PDF that conforms to PDF/UA-1 (ISO 14289-1:2014) and meets WCAG 2.1 AA where applicable.¹ That single combination satisfies almost every legal regime in scope.

Why "tagged PDF" is the foundation

A regular PDF page is, structurally, a positional content stream — glyphs at x/y coordinates per the ISO 32000-1 page model.² There is no semantic information about which glyphs form a heading, which a paragraph, which a table caption. A screen reader looking at this page has nothing to navigate by.

A tagged PDF adds a structure tree — a hierarchical map from content to semantic roles (Document → Section → H1 → P → Figure → Table). Screen readers walk this tree to read the document in a meaningful order: announce the heading, then the paragraph, then identify the figure and announce its alt text, then announce the table with row/column headers. Users can jump between headings, list items, and sections the same way sighted users jump by scrolling.

Tagged PDF is mandatory for PDF/UA-1, required by every WCAG-aligned regulation, and the difference between a PDF that works for screen-reader users and one that does not. If you only fix one thing, fix tagging.

The ten-item accessibility checklist

Every accessible PDF satisfies these ten items. The first four are mandatory; the rest are required by PDF/UA-1 and most accessibility audits.

Item	What it means	How to check
Document is "tagged"	A tagged PDF has a structure tree mapping content to semantic roles (H1, H2, P, Figure, Table, List). Screen readers use this to navigate.	Open File → Properties (Adobe Reader); check the "Tagged PDF" field. ScoutMyTool's Tagged PDF Validator reports the tagging state explicitly.
Headings use proper structure tags	H1, H2, H3 etc. (or their PDF equivalents) — not just bigger / bolder text styled as headings.	In Adobe Acrobat Pro, the Tags panel shows the structure tree. ScoutMyTool's validator flags missing or out-of-sequence headings.
Images have alt text	Every meaningful image needs descriptive alt text. Decorative images should be marked as artifacts (so screen readers skip them).	ScoutMyTool's Image Alt Text Audit tool flags every image and reports which ones lack alt text or have placeholder alt.
Reading order is logical	Screen readers traverse the page in tag-tree order. If the order does not match visual reading order (left-to-right, top-to-bottom in most languages), users hear the page out of sequence.	ScoutMyTool's Reading Order Audit tool extracts the tree order and lets you compare against visual layout.
Tables have proper header markup	Data tables need <TH> cells with scope (row or column) so screen readers can announce "Quarter 3, Revenue: $1.2M" rather than reading cells in raw order.	The Tags panel in any accessibility-aware PDF editor; validators flag tables that have <TD> only and no <TH>.
Document language is declared	The /Lang entry in the catalog tells screen readers which language to use for pronunciation (English vs. French vs. Japanese).	File → Properties → Advanced → Reading Options → Language. Validators flag PDFs with no language declaration.
Form fields have labels and tab order	Each fillable form field needs a programmatic label that the screen reader announces, plus a tab order that matches visual layout.	Adobe Acrobat's Forms panel; ScoutMyTool's form-field inspector flags unlabelled fields.
Colour contrast is adequate	Text against background must meet WCAG 2.1 AA contrast ratios (4.5:1 for normal text, 3:1 for large text).	Manual review with a contrast checker (WebAIM Contrast Checker, axe DevTools). Hard to automate inside a PDF tool.
No content rendered as image-only	Pages that are scanned photos of text (with no text layer) are completely inaccessible. Run OCR to add a searchable, screen-readable text layer.	Open the PDF and try to select text. If you cannot select anything, the page is image-only.
No automatic time-outs or auto-advancing	Some interactive PDFs auto-advance pages or close fields after a timeout. Users with motor or cognitive disabilities need control.	Manual review of any JavaScript or interactive features.

Producing an accessible PDF — from source to validated output

Use proper heading styles in the source document. Word, Google Docs, and LibreOffice all support Heading 1 / Heading 2 / Heading 3 styles. Apply them — do not just make the text bigger and bolder. The PDF tag tree is built from these styles.
Add alt text to every meaningful image. In Word: right-click the image → View Alt Text → write a short, descriptive sentence. Mark decorative images as decorative. Same workflow in Google Docs and LibreOffice.
Use the document language setting. Word: File → Options → Language. Google Docs: File → Language. The PDF inherits the language declaration, which screen readers use to pick the right pronunciation engine.
Mark tables as data tables with header rows. Word and Google Docs both support the "Header row" property on tables. Use it; do not just bold the top row visually.
Export with tagging enabled. Word: Save As PDF → Options → tick "Document structure tags for accessibility". Google Docs: download as PDF preserves tags by default. LibreOffice: Export As PDF → tick "Tagged PDF".
If you start from a scanned PDF, run OCR first. Without OCR, the file is image-only and fundamentally inaccessible. Add a text layer using Adobe Acrobat Pro OCR, ocrmypdf, or a cloud OCR service.
Validate the result. Use ScoutMyTool's Tagged PDF Validator to report on tagging state. Use Image Alt Text Audit to flag missing alt text. Use Reading Order Audit to confirm the tag-tree order matches visual reading order. For Section 508 audits, run PAC 2024 (free) or Adobe Acrobat Pro's Accessibility Check.
Test with an actual screen reader. The validators catch structural problems; only a screen reader walk-through catches alt-text quality and reading-order quirks. NVDA on Windows is free; VoiceOver on macOS is free. Listen to the first thirty seconds and the last thirty seconds of any document before publishing — that catches most issues.

Free PDF accessibility validators

PAC 2024 (PDF Accessibility Checker) — Free Windows desktop app from the Swiss non-profit Access for All. Produces detailed reports against PDF/UA-1. The de-facto standard for Section 508 and EU public-sector audits.
ScoutMyTool Tagged PDF Validator — Browser-based, reports on tagging state, structure tree depth, missing alt text, and reading order. Pair with the Image Alt Text Audit and Reading Order Audit tools for a fuller picture. All client-side, no upload.
Adobe Acrobat Pro Accessibility Check — Paid, but the most comprehensive automated check. The "Make Accessible" wizard walks you through applying tags retroactively to an untagged PDF.
axesPDF QuickFix — Free web tool from axes4 GmbH for quick automated fixes to common accessibility issues. Reasonable as a triage step before a fuller audit.

Tagged PDF Validator — the primary tool referenced.
Image Alt Text Audit — flag images that lack alt text.
Reading Order Audit — verify tag-tree order matches visual layout.
Add Tagged Bookmarks from HTML — pre-populate accessible bookmark outlines from source HTML.
PDF Form Fill — fill accessible forms.
PDF OCR — add a text layer to scanned PDFs, the foundation for any tagging.
PDF table of contents generator — bookmark outlines are part of accessible navigation.
Word to PDF — sister article emphasising the "Create bookmarks using: Headings" toggle that pairs with accessibility.

Frequently asked questions

What is a "tagged PDF" and why does it matter?: A tagged PDF has a structure tree — a hierarchical map from page content (text runs, images, table cells, list items) to semantic roles (heading, paragraph, figure, table, list). Screen readers (JAWS, NVDA, VoiceOver, Narrator) walk this tree to announce the document in a meaningful order — "Heading 1: Annual Report", then "Section 2: Financial Overview", then the figure caption and the table rows. An untagged PDF is a flat positional dump of glyphs; the screen reader has nothing to navigate by, and the user experience is roughly equivalent to listening to a randomised list of words. Tagged PDFs are mandatory for PDF/UA-1 and effectively required for WCAG 2.1 AA compliance.
How do I make a tagged PDF from a Word document?: Use Word's built-in PDF exporter (Save As → PDF) and tick "Document structure tags for accessibility" in the Options dialog. The export uses your Heading 1 / Heading 2 / Heading 3 styles to build the tag tree — so the most important upstream step is to use proper heading styles in Word, not just bigger fonts. The same applies to Google Docs (File → Download → PDF; preserves tags by default) and LibreOffice Writer (Export as PDF → "Tagged PDF" checkbox). If your source document does not use heading styles, no tagged output is possible regardless of the export tool.
My PDF is already published — can I add accessibility tags after the fact?: Yes, but it is more work than tagging at export time. Adobe Acrobat Pro has an "Auto-Tag" feature plus a manual Tags panel for fixing what auto-tagging misses; this is the most thorough path but requires the paid Acrobat Pro. Free alternatives: re-export from the source document with proper heading styles, or use a tagging tool like axesPDF, Pave PDF, or the open-source Pdfsam Enhanced. ScoutMyTool's tagged-PDF validator reports what is missing so you know what to fix, but does not currently retag automatically.
How do I check whether my PDF is actually accessible?: Run it through a validator. The free ones: PAC 2024 (PDF Accessibility Checker, by Access for All) runs as a Windows desktop app and produces a detailed report; axesPDF QuickFix is a free web tool from axes4 GmbH; ScoutMyTool's Tagged PDF Validator runs in your browser. For Section 508 / WCAG compliance audits, Adobe Acrobat Pro's Accessibility Check is the closest thing to an official tool. None of the automated checkers catches everything — final accessibility always requires human review (especially of alt text quality and reading order).
What is the difference between "alt text" and "actual text" in a PDF?: Alt text describes what an image conveys for screen-reader users — e.g., "Bar chart showing Q3 revenue of $1.2M, up 15% year-over-year". It is set on Figure tags. Actual Text is a related attribute that provides the textual equivalent of content that is rendered as something other than text — for example, a logo rendered as a vector graphic whose actual text content is "Acme Inc.". Most simple cases need only alt text; Actual Text becomes relevant when the visual rendering is fundamentally a glyph (a hand-drawn signature, a stylised logo) and the screen reader needs to know the underlying word.
Do scanned PDFs need OCR before they can be accessible?: Yes, absolutely. An image-only scanned PDF contains zero text — the page is a photograph of a document. Screen readers find nothing to announce. Run the scan through OCR (Adobe Acrobat Pro's OCR, ocrmypdf on Linux, Tesseract via a wrapper, or any cloud OCR service) to add a text layer beneath the image. Then tag the result. The OCR text layer is what every accessibility validator and screen reader will consume. Without OCR, a scanned PDF is fundamentally inaccessible no matter how well-tagged it is.
What are the legal consequences of shipping an inaccessible PDF?: It depends on jurisdiction and sector. US federal agencies are bound by Section 508 of the Rehabilitation Act and can face procurement complaints and civil enforcement; federal contractors may have contracts cancelled. US private businesses serving the public are subject to ADA Title III lawsuits — case law (Robles v. Domino's and others) has applied the ADA to digital content including PDFs. In the EU, public-sector bodies are subject to Directive 2016/2102 and the European Accessibility Act extends accessibility obligations to most consumer-facing businesses from June 2025. The financial exposure is real, and the cost of building accessible PDFs from the start is far lower than retrofitting after a complaint.

Validate your PDF's accessibility, free

Browser-based PDF/UA validator. No upload — your PDF stays on your machine while we check tagging, alt text, and reading order.

Open the free Tagged PDF Validator →