PDF Accessibility: The ADA Gap Your Scanner Misses

Here is an uncomfortable fact most accessibility vendors won't lead with: your website can pass every automated scan — ours included — while the menu, the price list, the intake form, and the annual report you link to as PDFs quietly fail the ADA. If a blind customer can't read the document that actually matters to them, it doesn't help that the page around it was perfect. PDFs are the accessibility gap almost nobody scans, and plaintiffs have noticed.

Why PDFs Are the Gap Nobody Talks About

A PDF is not a web page. It's a self-contained document with its own internal structure, and to a screen reader that structure is either present or it isn't. A great many PDFs on the web are effectively pictures of text — a page was designed in Word or InDesign, exported or scanned, and shipped with no tags, no reading order, and no alternative text. A sighted person sees a tidy document. A screen-reader user hears silence, or a garbled stream of characters in whatever order the software guesses.

This matters because the ADA has never been about your homepage in isolation. Courts and the DOJ treat the goods, services, and information a business offers online as what must be accessible — and for most organizations, the real information lives in documents: restaurant menus, insurance summaries, government forms, course syllabi, financial statements, product manuals. Our ADA website compliance guide walks through why the legal test is about the visitor's experience, not the file format you happened to choose.

What Actually Makes a PDF Accessible

“Accessible PDF” has a real definition — the PDF/UA standard and WCAG (opens in new tab) — and it comes down to a handful of properties that have to be baked into the file itself:

Tags. A tagged PDF carries a hidden structure tree — headings, paragraphs, lists, tables — that tells assistive tech what each chunk of content is. Untagged PDFs are the single most common failure.
Logical reading order. Tags also define the order content is read aloud. A two-column newsletter that looks fine can read as an incoherent zig-zag if the order wasn't set deliberately.
Real text, not an image. Scanned documents are images until you run OCR. No selectable text means nothing to announce.
Alt text on images and charts. The same rule as the web — if a graphic carries meaning, it needs a description. Our guide to writing alt text applies here almost word for word.
Marked-up tables, a document title, and a language setting. Data tables need header cells, the file needs a real title (not “Untitled-3.pdf”), and a declared language so the screen reader picks the right voice.

Why Your Web Scanner Gives PDFs a Free Pass

Here is the part we'd rather you hear from us than from a demand letter. CompliaScan, like every serious automated web scanner, is built on axe-core (opens in new tab), which evaluates the rendered HTMLa browser produces. When our crawler reaches a link to a PDF, it sees a link — it does not open the file and inspect its tag tree. The document's internal accessibility is simply outside what an HTML engine can assess.

That's not a CompliaScan limitation so much as a category limitation, and it's worth being blunt about: automated testing of any kind reliably catches only about 30–40% of WCAG success criteria, and inside-the-PDF conformance isn't one of them. Anyone who tells you a single web crawler certifies your PDFs as compliant is selling you something. What a good web scan can do is find whereyour documents live — every page that links to a PDF, so you know the size of the problem. Run your site through the ADA compliance checker or the WCAG checker to map your pages, then treat the linked documents as a separate workstream.

Want to know where your site stands?

Run a free scan →

Where PDFs Fail in the Real World

The theory is one thing; the failures we see over and over are remarkably consistent:

The scanned menu or flyer. A photo of a printed page, uploaded as a PDF. Zero selectable text. This is the classic restaurant lawsuit exhibit.
The “fillable” form that isn't. Application and intake PDFs with form fields that have no labels, no logical tab order, and no way to know which box is which without seeing the page.
The data-heavy report. Annual reports and price lists full of tables that were laid out visually with no header markup, so a screen reader reads numbers with no idea what column or row they belong to.
The exported slide deck. A presentation saved to PDF, where every slide is one flat image and the reading order is whatever the export tool decided.

Notice that every one of these is a document a customer genuinely needs to transact with you — not decoration. That's exactly why they draw complaints.

How to Make Your PDFs Accessible

You don't have to remediate a decade of documents overnight. A pragmatic, repeatable process handles it:

Fix it at the source. Accessibility is far easier to build in the authoring tool than to bolt on afterward. Use real heading styles, list styles, and alt text in Word, Google Docs, or InDesign, then export with tagging turned on. Remediating an exported PDF by hand should be the exception, not the workflow.
OCR anything scanned. If a document is an image, run optical character recognition to turn it into real text before you do anything else. No text, no accessibility, full stop.
Check tags, reading order, and alt text. Use a PDF-aware tool — Adobe Acrobat's accessibility checker or the free PAC checker (opens in new tab) — because your web scanner can't do this part.
Test with an actual screen reader. Open the file and listen. Does it read in the right order? Are tables coherent? This is the manual step no automated tool replaces — the same lesson as the rest of a proper accessibility audit.
Ask the honest question: does this need to be a PDF at all? Often the most accessible fix is to publish the content as a normal HTML page and keep the PDF as an optional download. A web page is easier to make accessible, easier to update, and easier to scan. Work your document inventory against a WCAG checklist so nothing slips through.

The Section 508 and ADA Angle

If you sell to government or receive federal funding, PDF accessibility isn't optional — Section 508 explicitly covers electronic documents, and “we posted a PDF” is not a defense. We cover that regime in Section 508 Compliance Explained. For private businesses under the ADA there's no line-item “PDF rule,” but the outcome is the same: if a document is part of how you serve customers, it has to be usable by everyone.

One thing no honest vendor will promise you: there is no product, overlay, or scan that makes your documents “lawsuit-proof.” What reduces real risk is boring and effective — accessible source files, a real remediation pass on the documents that matter, and ongoing checks as you publish new ones. If you want a sense of what continuous coverage looks like across your whole site, our pricing page lays out the monitoring tiers — and note that any AI-assisted fix suggestions in CompliaScan run on your own API key, so you're never paying us a markup to explain a failure.

See your lawsuit risk in 30 seconds

Over 5,100 ADA website lawsuits were filed in 2025 — a 20% year-over-year increase. Scan your site now and know exactly how exposed you are before a plaintiff's firm runs the same check.

Free scan · No signup required · Results in ~30 seconds

See plan pricing Read the compliance guides Free accessibility tools