Yes. If a PDF is posted on a website that serves the public, courts and the DOJ treat it as part of that site's content, so it falls under the same ADA expectations as the rest of your pages. A restaurant menu, an intake form, or an annual report saved as a PDF has to be usable by someone relying on a screen reader or keyboard. A scanned-image PDF with no real text, no tags, and no reading order is functionally a locked door, and PDF ADA compliance is one of the first things a serial plaintiff's tester will probe.
The trap is that PDFs feel finished. You export from Word, Canva, or a design tool and move on, but that export usually strips the structure assistive technology depends on, leaving a file that looks perfect on screen and reads as gibberish to a screen reader.
Why is PDF ADA compliance a common weak spot?
Digital-accessibility litigation is not slowing down: UsableNet counted more than 5,000 web-accessibility lawsuits in 2025, up roughly 20% over 2024, and food service made up about 18% of them. Food service runs on one document above all, the PDF menu.
PDFs draw fire because they are easy for a tester to check and hard to defend. A tester opens the file, turns on a screen reader, and within seconds knows whether it has real text or is just a flat image. The failure is binary and captured in one screenshot.
These documents also tend to be the high-value ones: a menu decides whether a blind diner can order, and a form is how someone requests service or pays. When the most important content is the least accessible, that is exactly the gap a demand letter targets. For the broader pattern, see how ADA serial plaintiffs pick targets.
How do I know if my PDF is actually accessible?
You can screen most problems in a couple of minutes. Run these checks on every public-facing PDF:
- Select the text. Try to highlight a sentence with your cursor. If nothing selects, the file is a scanned image with no real text underneath and a screen reader has nothing to read, the single most common and most serious failure.
- Check for tags. In Acrobat, open the Tags panel. A tagged PDF has a structure tree of headings, paragraphs, lists, and tables. "No Tags available" means assistive technology gets no reading order.
- Read the reading order. Use Acrobat's accessibility checker or the reflow view to confirm content flows in a logical sequence. Multi-column menus and forms frequently read out of order.
- Look at form fields. Every field in a fillable form needs a programmatic label; an unlabeled box announces only as "edit text." Our guide to the most common accessible form mistakes covers labels in depth.
- Confirm alt text on images. Logos, diagrams, and charts inside the PDF each need a text alternative, the same rule that applies to web-page images.
Treat the built-in checker the way you should treat any scanner: a passing report means the file passes automated scans, not that it is fully conformant. Automated tools detect only about a third of WCAG 2.2 success criteria; reading order, meaningful sequence, and whether alt text is actually descriptive all require human judgment.
How do I fix an inaccessible PDF?
There are two honest paths, and the right one depends on how the document is used.
Option 1: Replace the PDF with an HTML page
For menus, this is almost always the better answer. An HTML menu is easier to make accessible, easier to update, and helps SEO because search engines read it as real page content. If your menu, service list, or price sheet lives only in a PDF, rebuild it as a web page and retire the file, and do the same with short reports and one-page notices.
Option 2: Remediate the PDF properly
When the document genuinely needs to stay a PDF, a signed form, a formatted report, a file meant for download, it has to be remediated. In Acrobat that means running optical character recognition on scanned pages so the text is real, adding a tag structure, setting a logical reading order, writing alt text for every meaningful image, labeling form fields, marking the document language, and giving the file a title. The target is WCAG 2.2 AA, the benchmark courts, the DOJ rule, and the EU all reference.
Going forward, fix the source, not just the export. Use built-in heading styles in Word or Google Docs, add alt text before you export, and choose the "tagged PDF" option. A document authored with structure exports as a tagged PDF; one formatted with manual spacing exports as a mess.
What about the overlay widget that claims to fix my PDFs?
Be skeptical. A third-party "compliance" overlay, a script you paste in that promises to make a broken site conformant, does not fix the PDF on your server. The file downloads to the user's device and opens in their own reader, entirely outside the overlay's reach. Any product that markets itself as making your documents compliant is selling something it cannot deliver.
This is real legal exposure. In January 2025 the FTC announced a $1 million action against accessiBe over deceptive claims that its widget could make any website WCAG-compliant, and UsableNet repeatedly finds that hundreds of companies sued each year already had a widget installed. For the full breakdown, read why overlay widgets fail.
Draw the distinction the marketing blurs: a genuine accessibility preference widget, the kind that lets a visitor bump up text size or contrast on a site already built correctly, is a fine convenience and makes no compliance claim. ADA Fail runs one on its own site. The problem is never the preference button; it is the surface-layer script sold as a compliance shortcut, and neither one touches your PDFs.
What should I do first?
Inventory before you remediate. Run a site:yourdomain.com filetype:pdf search to find every public PDF, then sort them by how critical and public each one is. Menus, intake forms, and anything a customer must open to transact go to the top; archived files nobody links to can wait or be deleted outright, which is itself a legitimate fix.
Then decide replace-or-remediate for each, starting with the highest-risk documents. For a second set of eyes on which files are exposed, a free accessibility audit from ADA Fail will flag the PDFs a tester would hit first.
PDFs are one of the cheapest liabilities to close and one of the most overlooked. A menu a blind diner can read and a form a screen-reader user can complete are well within reach. Start with a free audit to see which documents put you at risk and what it takes to fix them.
Frequently asked questions
Does a PDF menu really need to be accessible if I also have an online ordering system?
Yes. An inaccessible menu is a barrier even if another path exists. The Robles v. Domino's Pizza decision established that a website or app tied to a physical location is covered by the ADA, and food service accounts for roughly 18% of web-accessibility suits. The safest move is to publish your menu as an accessible HTML page rather than relying on a PDF at all.
Can Word or Google Docs export an accessible PDF automatically?
Only if the source document is built with real structure. If you use built-in heading styles, add alt text to images, use actual list and table tools instead of manual formatting, and choose the tagged-export option, the resulting PDF carries much of what a screen reader needs. If the document is formatted by hand with spacing and font-size tricks, the export will not be accessible no matter which button you press.
How much does PDF remediation cost compared to getting sued?
Remediating a handful of documents is a modest expense next to litigation. Most web-accessibility cases settle for between $10,000 and $75,000 plus a remediation commitment, with an average settlement cost north of $30,000 before attorney's fees. Replacing a PDF menu or remediating a form is a fraction of that, and it removes one of the easiest targets a tester can find. See our breakdown of what an ADA website lawsuit actually costs.