An accessible PDF is a tagged document whose structure — headings, reading order, alt text, lists, and table headers — can be read aloud and navigated by assistive technology. The technical standard is PDF/UA (ISO 14289), and it maps directly to WCAG 2.1 AA, the benchmark used in ADA web-accessibility cases.
Why PDFs are a common compliance gap
Most businesses get their HTML pages partly right and forget their PDFs entirely. Menus, intake forms, financial statements, brochures, and policy documents get uploaded straight from Word or a scanner — untagged, unstructured, and invisible to a screen reader.
That matters because PDFs are content. Under ADA Title III, the documents you publish are part of your site, and they’re held to the same standard as the rest of it. For public-sector organizations, the DOJ’s 2024 Title II web rule made the expectation explicit. In the private sector, accessibility demand letters routinely call out inaccessible PDFs by name, because they’re easy to spot and hard to dispute.
A scanned PDF is the worst case: it’s a flat image of text. To a sighted user it looks fine; to a screen reader, there’s nothing there at all. This is why PDFs are one of the highest-impact, most-overlooked items in any accessibility audit.
What makes a PDF accessible
A PDF is accessible when assistive technology can understand both what the content is and what order to read it in. That comes down to a handful of building blocks.
| Element | What it does | WCAG link |
|---|---|---|
| Tags | A hidden structure tree (<H1>, <P>, <Table>, <Figure>) that tells AT what each item is | 1.3.1 Info and Relationships |
| Reading order | The sequence in which content is announced | 1.3.2 Meaningful Sequence |
| Alt text | Text descriptions for images, charts, and logos | 1.1.1 Non-text Content |
| Headings | A logical H1–H6 outline for navigation | 2.4.6 Headings and Labels |
| Document language | Tells AT which language (and pronunciation) to use | 3.1.1 Language of Page |
| Color contrast | Text that stays legible for low-vision users | 1.4.3 Contrast |
| Form fields & tooltips | Labeled, keyboard-operable interactive fields | 3.3.2 Labels or Instructions |
These follow the same POUR principles — Perceivable, Operable, Understandable, Robust — that govern web accessibility, because a PDF is just another document an assistive technology has to interpret.
Tags: the part that actually gets read
Tags are the most important and most misunderstood piece. The text you see on screen and the tags a screen reader reads are two separate layers. A document can look perfect and still be unreadable if it’s untagged or mis-tagged. Tagging — adding and correcting that hidden structure — is the core of PDF remediation.
Reading order
Even a tagged PDF fails if the order is wrong. Autotagging tools regularly scramble multi-column layouts, pull captions before images, or read a sidebar in the middle of a paragraph. Reading order has to be checked visually against the tag tree, which is manual work no tool can fully automate.
Headings, lists, and tables
Screen-reader users navigate documents by jumping between headings, exactly as they do on web pages. Real heading tags (not just bigger, bold text) make a long PDF usable. Lists need list tags, and data tables need designated header cells so each value announces its row and column context — without them, a table is read as a meaningless stream of numbers.
Alt text and decorative artifacts
Every meaningful image, chart, or linked logo needs alt text that conveys its content and function. Purely decorative graphics should be marked as artifacts so assistive technology skips them instead of announcing noise.
PDF/UA: the standard to aim for
PDF/UA (ISO 14289) is the international specification for accessible PDFs. It spells out precisely how tags, alt text, reading order, and metadata must be implemented. You don’t have to recite the spec, but it’s the bar professional remediation works toward, and a PDF/UA-conformant file generally satisfies the document-level criteria of WCAG 2.1 AA.
PDF/UA and WCAG are complementary: WCAG defines what accessibility means across the web, while PDF/UA defines how to achieve it inside the PDF format specifically. For a wider view of how these standards fit together, see ADA vs Section 508 vs WCAG. (Section 508 requires federal agencies and their contractors to meet WCAG 2.0 AA for documents, so accessible PDFs are mandatory in government procurement, often documented in a VPAT.)
How to make a PDF accessible, step by step
The process below works for most documents. The single biggest lever is starting upstream: a well-structured source file exports to a dramatically cleaner tagged PDF than anything you can patch together afterward.
- Build structure in the source — use real heading styles, lists, and table headers in Word, InDesign, or Google Docs before you export.
- Export tagged and set the language — choose “tagged PDF” on export, or run Autotag in Acrobat Pro, then set the document language.
- Fix the reading order — confirm content flows correctly in the Order and Tags panels.
- Add alt text and mark decorative items — describe meaningful images; mark the rest as artifacts.
- Tag tables and form fields — set table header cells and give every form field a label and tooltip.
- Verify — run Acrobat’s Accessibility Check and a PDF/UA validator, then test with a real screen reader.
Why automated checks aren’t enough
Acrobat’s Accessibility Check and WebAIM-recommended validators are useful for catching missing tags, absent alt text, and untagged form fields. But they’re a starting point, not a verdict. A tool can confirm an image has alt text; it can’t tell you the alt text is wrong. It can confirm tags exist; it can’t tell you the reading order makes sense.
That gap is exactly why manual accessibility testing matters. Real conformance is verified by a person navigating the document with NVDA, JAWS, or VoiceOver and by keyboard alone — confirming the experience actually works, not just that the boxes are checked. For more on this split, see automated vs manual accessibility testing.
This is also why accessibility overlays don’t help with PDFs at all. Overlay widgets run as JavaScript on your HTML pages; they can’t reach inside a downloadable file to add tags, fix reading order, or write alt text. PDF accessibility is only ever achieved by remediating the file itself — there is no shortcut, and overlays don’t deliver one.
Get your PDFs fixed
If you have a library of menus, forms, or reports that need tagging, remediating them by hand is slow, detail-heavy work — and it’s exactly what we do. Curbcut’s accessibility remediation team tags your documents, corrects reading order, writes alt text, and verifies the result against WCAG and PDF/UA with real assistive technology. Not sure how many of your files are affected? Start with a free scan or book a quick conversation.
This guide is educational and isn’t legal advice. For questions about your specific ADA obligations or a demand letter, consult a qualified attorney.