This is a practical, plain-English checklist for making a PDF accessible enough to meet the expectations behind the ADA — which in practice means conforming to WCAG 2.1 Level AA and the PDF/UA technical standard. Work through it section by section. Most documents fail in the same predictable places, so even fixing the first few sections removes the majority of real-world barriers for the roughly 1 in 4 U.S. adults who live with a disability.
For the legal background behind why these requirements apply, see the PDF accessibility and ADA compliance guide. For the technical standards in depth, see the WCAG 2.2 & PDF/UA guide.
This is general information, not legal advice.
How to use this checklist
Each item is a checkbox. An unchecked box is a potential barrier — and often the exact thing a screen-reader user (or a plaintiff's tester) will hit first. Automated tools can confirm many of these, but a few require a human reading the document with a screen reader. Those are flagged in the final section.
Document setup
The foundation. These are quick wins that screen readers depend on before they read a single word.
- Document title is set in the file's properties (not just the filename), and the document is configured to show the title rather than the filename in the window.
- Document language is specified (for example, English) so a screen reader uses the right pronunciation rules. Mark passages in other languages individually.
- Security settings do not block assistive technology. Some "copy protection" settings prevent screen readers from extracting text — make sure text access is permitted.
Structure and reading order
This is where most documents fail, and it is the single most important section.
- The document is tagged. Tags are the invisible structure that tells a screen reader what each element is. An untagged PDF is effectively unreadable.
- Reading order follows the visual/logical order. Content should be announced in the order a person would naturally read it, not the order elements happen to sit in the file.
- Real heading tags (H1, H2, H3…) are used for headings — not just bigger, bolder text. Headings let users navigate and understand the document's outline.
- Heading levels are nested logically without skipping levels arbitrarily.
If tags or reading order are unfamiliar, our guide to PDF tags and reading order walks through exactly how these work.
Text
Accessibility starts with text a machine can actually read.
- Text is real, selectable text — not a picture of text. If you can't select and copy a sentence with your cursor, neither can a screen reader.
- Scanned documents have been run through OCR (optical character recognition) to convert the image into selectable text, and the OCR output has been checked for accuracy.
Images
- Informative images have alternative text that conveys their meaning concisely. A logo, chart, or photo that carries information needs a text description.
- Decorative images are marked as artifacts so screen readers skip them instead of announcing meaningless content.
- Complex images (charts, diagrams) have a longer description nearby or in the alt text that explains the data, not just the label.
For the difference between good and useless descriptions, see alt text for images in PDFs.
Tables
Tables are read cell by cell, so the relationships have to be encoded.
- Tables use real table tags, not spaces or tab stops arranged to look like a grid.
- Header cells are marked as headers so a screen reader can announce "Row, Column = value" instead of a flat stream of numbers.
- Scope is set (row or column) on header cells in anything beyond the simplest table.
- Layout tables are avoided where possible; tables should hold data, not control page layout.
Lists and links
- Lists use real list tags so they're announced as "list, 3 items" rather than stray bullet characters.
- Link text is meaningful on its own. "Download the 2026 benefits form" works; "click here" or a bare URL read aloud does not.
Color and contrast
- Text meets minimum contrast against its background (the WCAG 2.1 AA threshold for normal text).
- Color is not the only way information is conveyed. "Fields in red are required" fails for users who can't perceive the color — pair it with text or a symbol.
Forms
Interactive PDFs add their own requirements.
- Every form field has a label (a tooltip/accessible name) that says what to enter.
- The tab order is logical, moving through fields the way a person would fill them out.
- Required fields and instructions are conveyed in text the screen reader can announce, not just visually.
The deeper mechanics live in our guide to accessible PDF forms, linked from the WCAG and PDF/UA pillar above.
Navigation
- Long documents have bookmarks (an outline) so users can jump between sections instead of paging through linearly.
- Page numbering is consistent between the document's content and the PDF page labels.
Verification
You cannot confirm accessibility by eye alone. Use both an automated check and a human test.
- Run an automated accessibility checker to catch missing tags, missing alt text, untitled documents, and structural errors. This is fast and catches the obvious failures.
- Do a manual screen-reader test. Listen to the document with a screen reader. Does the reading order make sense? Do images describe themselves? Do forms announce their labels? This is the step that catches the problems automated tools cannot — and it's the experience your users actually have.
| Verification method | Catches | Misses |
|---|---|---|
| Automated checker | Missing tags, alt text, title, language | Whether alt text is meaningful; whether reading order makes sense |
| Manual screen-reader test | Garbled reading order, useless alt text, broken forms | Nothing — but it's slower, so use it on priority documents |
When a document fails, don't start from scratch — see how to remediate an inaccessible PDF for an efficient fix-it workflow.
Key takeaways
- An accessible PDF needs the basics in place first: a title, a language, tags, and a logical reading order — these account for most failures.
- Real text (not images), meaningful alt text, properly tagged tables, and labeled form fields are the recurring problem areas.
- Color and contrast must work for users who can't perceive color, and links must make sense out of context.
- Verification takes two passes: an automated checker for obvious errors, plus a manual screen-reader test for the things tools can't judge.
- This checklist maps to WCAG 2.1 AA and PDF/UA, the standards courts and regulators expect — start with your highest-traffic, public-facing documents.
