The PDF on Your Website Is Probably Failing Every Accessibility Test You Just Passed

ClearPath Team · 2026-07-29 · 7 min read

You fixed your color contrast. You wrote real alt text. You tested your forms with a keyboard. Then somebody on your team uploaded a menu, a spec sheet, or an annual report as a PDF and linked it from the homepage, and nobody thought about it again. That file is now sitting on your site as a black box to anyone using a screen reader, and it's one of the most overlooked gaps in web accessibility today.

Why PDFs slip through the cracks

A PDF looks like a finished document, so teams treat it like one. But a PDF exported straight from Word, InDesign, or a scanner usually has no internal structure at all. There are no headings, no reading order, no tags telling a screen reader "this is a list" or "this is a table." Accessible PDF files are digital documents designed so that people with disabilities can read, navigate, and interact with the content effectively, meaning they must work with assistive technologies like screen readers and magnifiers. Without that structure, a screen reader either reads the file as one giant unbroken block of text or, in the case of a scanned image, reads nothing at all.

In practice, an "accessible" PDF is usually a tagged PDF, one that contains semantic structure information for headings, lists, tables, images, and more. That tagging has to happen deliberately. It doesn't come for free just because the document looks clean on screen. A tool like ClearPath can make the rest of that same page easier to read, with larger text, more contrast, and better screen reader navigation, but none of that reaches into the PDF file itself.

What actually makes a PDF accessible

There's no single checkbox for this. It's a handful of specific things that all need to be true at once:

• Tagged structure: The PDF should be saved as a tagged PDF, with a complete tags tree that represents the document's structure, including headings, paragraphs, lists, and tables.
• Logical reading order: the order a screen reader moves through content has to match the visual order a sighted reader would follow, including multi-column layouts and sidebars.
• Alt text on images and charts: any graphic that carries meaning needs a text description, the same rule that applies to images on your web pages.
• Real form fields: if your PDF has fillable fields, each one needs a label a screen reader can announce, not just a visual caption next to a blank box.
• Sufficient contrast: text and background colors in the PDF need to meet the same contrast ratios you'd apply anywhere else on your site.
• Searchable text, not scanned images: a PDF that's really just a photograph of a page has no text layer at all, which means screen readers, translation tools, and even copy-paste have nothing to work with.

The rules that actually apply to PDFs

Some businesses assume WCAG only covers HTML pages. It doesn't. WCAG 2.2 AA includes making documents and media accessible, so PDF files published on those sites should align with those guidelines, covering things like text alternatives, structure, and contrast. If your website is in scope for WCAG, the documents linked from it are too.

This is especially concrete for government entities right now. ADA Title II digital accessibility requires state and local governments to ensure that all digital content, including PDF documents, is accessible to people with disabilities in accordance with WCAG 2.1 Level A and AA standards. Public entities serving populations of 50,000 or more must comply by April 24, 2026, while smaller entities and special district governments have until April 26, 2027. That covers everything from city council agendas to court forms, not just the main site template.

Private businesses aren't off the hook either, even though the deadlines are less formal. Downloadable menus, brochures, and spec sheets show up constantly in accessibility complaints. In one mid-2025 litigation report, embedded menus, brochures, or downloadable PDFs that were not tagged or readable by screen readers contributed to lawsuit filings. A restaurant can have a perfectly accessible homepage and still get flagged because the actual menu is a flat, untagged PDF.

Widgets alone won't fix a broken PDF

It's worth being honest about something here. Accessibility overlays and widgets have taken heat for overpromising, and the data backs up some of that skepticism. One report found that despite having accessibility widgets installed, 456 ADA lawsuits were still filed against those websites, making up over 22% of total filings, which shows that simply adding a widget is not a comprehensive solution on its own. A PDF sitting on a server is a separate file with its own structure problems. No script running on your webpage can reach inside that document and rebuild its tags. ClearPath is honest about that boundary too: it improves how visitors experience your HTML pages, but it was never built to open, tag, or rewrite a PDF file.

How to actually fix your PDFs

1. Start with your highest traffic and highest stakes documents: application forms, menus, pricing sheets, and anything tied to a transaction or service.
2. Rebuild structure at the source when you can. Applying proper headings and styles in Word or InDesign before exporting saves far more time than fixing tags after the fact.
3. Run an automated checker, then verify by ear. Automated tools catch missing tags and alt text, but you still need to listen with an actual screen reader to catch reading order problems.
4. Replace scanned documents with real text-based PDFs wherever possible, or provide an accessible HTML version alongside the download.
5. Retag and retest every time the document is updated. An accessible PDF that gets edited in a rush and re-saved can lose its tags entirely.