Most accessibility programs fix the website and forget the PDFs. In 2026, inaccessible documents are one of the most overlooked — and most litigated — ADA risks. Here's the PDF/UA standard, the common failures, and how to audit before you get sued.
Most accessibility programs have the same blind spot. A team audits its website, fixes the contrast and the form labels, publishes an accessibility statement — and never touches the hundreds of PDFs sitting behind that website. The menus, the price lists, the account statements, the intake forms, the annual reports. In 2026, those documents are one of the most overlooked and most litigated ADA risks a business carries.
The reason is simple: a PDF is just as much "web content" as an HTML page when it's posted to your site, so it carries the same accessibility obligations under the ADA and Section 508. But PDFs are produced differently — exported from Word, InDesign, or a design tool, often with none of the structure a screen reader needs — which means they're frequently less accessible than the page that links to them. Here's what that means for your legal exposure, and how to fix it.
The web is broadly inaccessible — and PDFs are worse
Start with the backdrop. WebAIM's annual study of the top one million home pages has, for years, found detectable WCAG failures on the overwhelming majority of them — in the 2025 analysis, 94.8% of home pages had detectable WCAG 2 errors, and the 2026 study found the average number of errors per page actually rising as sites grow more complex. If the public-facing home pages of the world's biggest sites are this inaccessible, the documents hosted on them — which get far less scrutiny — are almost always worse.
PDFs fail for structural reasons that don't show up visually:
- No tags. An untagged PDF is, to a screen reader, an unstructured blob — it can't tell a heading from body text, or a table from a paragraph.
- No reading order. Visually correct, but the underlying content order is scrambled, so a screen reader reads it nonsensically.
- No alternative text on images, charts, and logos.
- Images of text — scanned documents or exported graphics where the "text" is actually a picture, completely invisible to assistive technology.
- Inaccessible form fields — fillable PDFs whose fields have no labels.
A sighted user sees a perfectly normal document. A screen reader user gets nothing, or nonsense. That gap is exactly what a plaintiff's tester documents.
Why PDFs show up in litigation
Inaccessible PDFs are increasingly named in ADA website lawsuits and demand letters, and the sectors most exposed are the ones that rely on documents to deliver core services:
- Healthcare — patient intake forms, benefit summaries, after-visit instructions, billing statements. A patient who can't read their own statement has a strong accessibility claim, and HHS Section 504 obligations raise the stakes further.
- Education — course materials, syllabi, financial-aid forms, and public documents, where inaccessible PDFs block students with disabilities from core academic functions.
- E-commerce and hospitality — PDF menus, product spec sheets, warranties, and receipts. Inaccessible PDF menus in particular have become a recurring citation in restaurant litigation.
- Finance and insurance — statements, disclosures, and policy documents that customers legally need to be able to read independently.
The common thread: these aren't marketing extras. They're documents people need to transact, get care, or exercise a right — which is precisely what makes blocking access to them legally serious.
A sighted user sees a normal document. A screen reader user gets nothing. That gap is what a plaintiff's tester documents.
The standard to build to: PDF/UA (ISO 14289)
For HTML, the benchmark is WCAG 2.2 AA. For PDFs, the equivalent technical standard is PDF/UA — ISO 14289 ("Universal Accessibility"). PDF/UA defines what a properly accessible PDF requires: a complete tag tree, a logical reading order, alternative text for meaningful images, correctly marked tables and lists, identified document language, and accessible form fields.
PDF/UA and WCAG are complementary, not competing — conforming to PDF/UA is how you satisfy the WCAG success criteria in the PDF format specifically. For US compliance purposes, a PDF that meets PDF/UA and the relevant WCAG 2.x AA criteria is what "accessible document" means in practice.
The most common PDF failures — and how to fix them
The good news mirrors the WCAG story: most PDF failures come from a short, fixable list.
1. Untagged documents
Fix: Add a proper tag structure — headings, paragraphs, lists, tables — either in the authoring tool (Word's styles export to tags) or in a PDF editor. Never rely on "auto-tag" alone; verify the result.
2. Wrong reading order
Fix: Check and correct the reading order in the tag tree so a screen reader follows the document the way a sighted reader would.
3. Missing alt text
Fix: Add concise, meaningful alternative text to informative images and charts; mark purely decorative images as artifacts so they're skipped.
4. Images of text / scanned PDFs
Fix: Run OCR to convert the image into real, selectable text — then tag and verify it. A scanned form is invisible to assistive technology until this is done.
5. Unlabeled form fields
Fix: Give every fillable field an accessible label and a logical tab order so it can be completed with a keyboard and a screen reader.
6. Missing document language and title
Fix: Set the document language and a descriptive title in the PDF properties so assistive technology announces the document correctly.
How to audit your documents before you get sued
A practical, defensible PDF accessibility program looks like this:
- Inventory your public PDFs. You almost certainly have more than you think — crawl your site for linked PDFs and list them.
- Prioritize by traffic and function. Fix the high-traffic, transactional, and service-critical documents first: forms people must complete, statements they must read, menus they must order from.
- Audit against PDF/UA. Use a real checker plus manual review — automated tools catch tags and structure, but reading order and meaningful alt text need human eyes.
- Remediate at the source where possible. Fix the authoring template (Word/InDesign) so newly produced documents are born accessible, not retrofitted one by one.
- Prefer accessible HTML over PDF when you can. For content that changes often — menus, pricing — an accessible HTML page is easier to keep conformant than a regenerated PDF.
- Monitor continuously. New documents get published constantly; a one-time cleanup decays. Ongoing monitoring keeps documents — and the pages that host them — conformant over time.
The bottom line
PDFs are the part of your digital estate most likely to be inaccessible and least likely to be checked — which is exactly why they've become a growing source of ADA and Section 508 liability in 2026. The standard exists (PDF/UA / ISO 14289), the failures are well understood, and most are fixable with proper tagging, reading order, and alt text. The businesses that get caught out are the ones who remediated the website and forgot the documents behind it. Inventory your PDFs, fix the ones people actually need, and keep them accessible — before a plaintiff's tester finds the ones you missed.
This article is for general information and is not legal advice. For guidance on your specific situation, consult a qualified attorney or accessibility professional.