PDF Accessibility — Making Documents Screen-Reader Friendly
A PDF that looks fine in your reader can be totally unusable to someone navigating by screen reader. The fix is mostly mechanical — tagging the document structure, supplying alt text for images, marking the reading order, and declaring the language — but it has to be done deliberately. Here is the practical checklist, in the order that matters.
What "tagged" means and why it is the foundation
A PDF visually places glyphs at coordinates on a page. For sighted readers that is enough — the eye reconstructs the structure (headings, paragraphs, tables) from layout cues. For a screen reader, layout cues are invisible. The reader needs an explicit description of the document's structure: this run of text is a level-2 heading, this group is a list, this is a paragraph, that is a table cell.
That description lives in a separate "tags tree" inside the PDF. A document with a tags tree is called a tagged PDF. A document without one is called an untagged PDF, and to a screen reader it is essentially a wall of text where every line break is the same as every paragraph break and there are no headings, no lists, no tables — just glyphs.
If you only do one thing for accessibility, make it producing tagged PDFs. Almost every modern authoring tool can do it: in Word, "Save As PDF" with the "document structure tags" option enabled; in Google Docs, the export is tagged by default; in LaTeX, the tagpdf package or pdfx handles it; in InDesign, it is on by default in modern versions. The legacy "print to PDF" path almost never produces tags — avoid it for documents that need to be accessible.
The accessibility checklist
1. Tags tree
Confirmed by opening the PDF in Acrobat (Pro) and checking that the "Tags" panel shows a hierarchy of headings, paragraphs and lists rather than being empty. Free alternative: PAC 2024 (PDF Accessibility Checker) reports tag presence.
2. Reading order
The order in which a screen reader announces content. By default it follows the tag order, which usually matches visual top-to-bottom, left-to-right reading. If your document has multi-column layouts, sidebars, footnotes or pull quotes, the reading order can get scrambled. Verify by stepping through the document with a screen reader (NVDA on Windows, VoiceOver on macOS, both free) and listening for content jumping unexpectedly.
3. Heading levels
Document outlines need a sensible hierarchy. H1 for the title, H2 for major sections, H3 for subsections, and so on without skipping levels. Avoid using "make this text big" formatting in place of real headings — visually they look the same; structurally one is a heading and the other is a paragraph styled to look like one. Screen-reader users navigate by heading level, so missing or wrongly-leveled headings cripple navigation.
4. Alt text on images
Every meaningful image needs an "alternate text" describing it. The description should convey the information the image carries, not literally describe what the image looks like. For a bar chart, the alt text should state the values, not say "a bar chart". For a decorative graphic that adds no information, mark it as decorative so the screen reader skips it rather than announcing "image" awkwardly.
5. Language declaration
The PDF's metadata should specify the document's primary language so the screen reader uses the correct pronunciation engine. A French document read with an English voice is not just awkward — many words are unintelligible. If sections of the document are in a different language, those sections need their own language tag too.
6. Tables marked as tables, with headers
A table tagged as a table lets the screen reader announce "row 3, column 2" and read column headers when navigating cells. A table that is just a grid of text boxes with no table structure is a navigational nightmare. When tagging tables, identify the header row and column so the reader can announce "Total Sales: 5,200" instead of just "5200".
7. Lists tagged as lists
Bulleted and numbered content needs to be tagged as a list so the reader announces "list with 5 items, bullet 1 of 5…" rather than reading items as separate paragraphs.
8. Form fields with labels
Every form field needs a tooltip or accessible label. "Last Name", "Date of Birth", and so on. Without labels, the screen reader announces "edit text" with no context, which is unusable.
9. Reading order matches visual order in tables
Even tagged tables can be wrong if the cell order in the tags tree does not follow the natural reading direction. Check by tabbing through the table cells with Acrobat's accessibility checker.
10. Document title set in metadata
Not the filename — the document's title metadata. Many readers display the title rather than the filename in the title bar; for screen readers, the title is what is announced when the file opens. Set it explicitly in the source document; do not leave it as the random "Untitled-1" the authoring tool defaulted to.
The PDF/UA standard
If you need to certify accessibility — say for procurement requirements or government tenders — produce PDF/UA-1 conformant files. PDF/UA is an ISO standard that specifies the structural requirements for accessibility, and it is verifiable by tools like PAC. A PDF/UA conformant file is essentially the checklist above made formal: tagged, structured, language-declared, alt-texted, properly titled.
Note that PDF/UA conformance does not guarantee the document is genuinely usable — only that it follows the rules. A PDF can be PDF/UA conformant but have unhelpful alt text or scrambled reading order. Use the standard as a baseline, not as a substitute for testing with a real screen reader.
Quick verification workflow
- Open the file in a screen reader (NVDA on Windows, VoiceOver on macOS).
- Navigate by heading. If the headings come in the right order at the right levels, your structure is good.
- Encounter every image. Alt text should be informative; decorative images should not announce.
- Tab through any forms. Every field should announce a meaningful label.
- Listen to a paragraph or two. The pronunciation engine should match the language.
This takes about 5 minutes per document and catches almost every accessibility issue before a real user encounters it.
Cases that are genuinely hard
Some documents are difficult to make accessible no matter how careful you are:
- Scanned PDFs. Without OCR they are images of text — a screen reader has nothing to read. OCR creates a text layer that helps, but the alt text and structure still need to be added separately.
- Heavily designed magazines and brochures. Multi-column layouts with floating quotes and embedded captions are hard to express in a linear reading order. Sometimes a separate accessible version (a tagged Word document or a plain HTML version) is the right answer.
- Mathematical and chemical notation. Standard PDF tags do not handle equations well. MathML tagging via tagged PDFs is possible but requires specialist tooling.
- Interactive forms with conditional logic. Tagging gets you most of the way; complex form interactions often need additional ARIA-like annotations that not every reader honours.
Why this matters even if your audience seems unaffected
Accessibility is sometimes treated as a niche concern, but documents move. A report you produced for an internal audience ends up shared externally; a contract template you wrote in 2024 is the document a partner organisation hands to a job applicant in 2027. You do not get to choose which documents will eventually be opened by someone who needs accessibility, so the safest default is to produce all of them accessibly. The marginal cost of doing it correctly during authoring is small. The cost of retrofitting an existing untagged PDF is significant.