Are PDFs on Your Website an ADA Risk? Making Documents Accessible

Updated September 28, 2026 · 7 min read

Short answer: Yes, PDFs can be a risk. Inaccessible PDFs are part of a website's content, and scanned images of text, missing tags and wrong reading order can make them unusable with a screen reader. Fix or replace the ones people rely on, and use HTML where practical.

Why PDFs matter for website accessibility

Many small business sites treat PDFs as an afterthought. A menu, price list, intake form, brochure or policy gets exported from a design tool or scanned from paper and uploaded. It looks fine to a sighted visitor, so nobody checks it.

For a person using a screen reader, screen magnifier, or voice control, the same file can be unreadable. Accessibility standards such as the WCAG success criteria apply to web content generally, and documents you publish for visitors are usually treated as part of that content. Whether a specific PDF is legally covered can vary, and courts do not always agree on details. This is not legal advice; if you have a legal question, talk to an attorney.

In practice, PDFs are a common item in accessibility complaints and demand letters because they are easy to test and easy to find. If you have received a letter, see what to do with an ADA website demand letter.

The four most common PDF problems

1. Scanned PDFs with no real text

A scanned PDF is just a picture of a page. There is no text for a screen reader to read, so the visitor hears nothing or hears "image" for each page. This is the same underlying issue as WCAG 1.1.1 Non-text Content: information conveyed as an image needs a text equivalent.

Quick test: open the PDF and try to select a sentence with your cursor. If you can only drag a box around the whole page, or nothing highlights, it is probably an image. Searching for a word with Ctrl+F (Cmd+F on Mac) is another check.

The usual fix is optical character recognition (OCR), which adds a text layer. OCR is not perfect. Check the output for misread words, dropped numbers and garbled tables, because a wrong price or phone number is worse than a missing one.

2. Missing tags

Tags are the hidden structure inside a PDF that tells assistive technology what each piece of content is: a heading, paragraph, list, table or link. Without tags, a screen reader has little to go on and may read everything as one flat block.

Tagging supports the same idea as WCAG 1.3.1 Info and Relationships: structure that is visible on screen should also be available programmatically. A well-tagged document has:

Real headings (H1, H2, and so on) in a logical order
Lists marked up as lists
Tables with header cells identified
Alternative text for meaningful images, and decorative images marked as artifacts
Links with meaningful text, in line with WCAG 2.4.4 Link Purpose (In Context)

3. Wrong reading order

Even a tagged PDF can be read in the wrong order. This happens often with multi-column layouts, sidebars, pull quotes and text boxes. A screen reader follows the tag order, not the visual layout, so a sidebar might be read in the middle of a sentence.

Acrobat's Reading Order tool and the Tags panel let you inspect and reorder content. The best prevention is to build the document properly at the source, in Word, InDesign or Google Docs, rather than repairing it afterward.

4. Missing document basics

Some issues are small but quick to fix:

Document title. Set a descriptive title in the document properties and make sure it displays in the title bar (compare WCAG 2.4.2 Page Titled).
Language. Set the document language so screen readers use the right pronunciation (compare WCAG 3.1.1 Language of Page).
Color contrast. Light gray text on white is hard to read in a PDF as anywhere else. See WCAG 1.4.3 Contrast (Minimum).
Form fields. Fillable PDF forms need labels, tab order and instructions, as in WCAG 3.3.2 Labels or Instructions.

Quick reference: problem, check, fix

Problem	How to check	Typical fix
Scanned, no text	Try selecting text or searching	Re-export from source, or run OCR and proofread
No tags	Acrobat accessibility check, or a tool such as PAC	Export with tags from the source app, then repair
Wrong reading order	Read with a screen reader or check the Tags panel	Reorder tags, simplify the layout
No title or language	Document Properties	Set both, then re-save
Unlabeled form fields	Tab through the form, run a checker	Add field labels and tooltips

Automated PDF checkers catch only some problems. Whether alt text is meaningful or the reading order makes sense still needs a human, ideally with a screen reader.

How to make accessible PDFs in the first place

Fixing a finished PDF is slower than building it well. If you control the source file:

Use real styles for headings, lists and tables instead of manual formatting.
Add alt text to meaningful images before exporting.
Keep layouts simple. Avoid text boxes and multiple columns where you can.
Export to PDF with tags enabled (in Word this is the "Document structure tags for accessibility" option).
Open the result and run an accessibility check, then read through it once with a screen reader.

If you only have a scan or a flattened file, ask whether the original source still exists. Recreating from the source is often faster than repairing.

When to replace a PDF with an HTML page

A PDF is a fixed-layout format built for print. On the web, an HTML page is usually easier to make accessible and easier for everyone to use. HTML text reflows on small screens and when zoomed (see WCAG 1.4.4 Resize Text), and it works with headings, landmarks and keyboard navigation out of the box.

Consider HTML instead of a PDF when the content is:

A menu, price list, hours or service description. Restaurants especially benefit; see restaurant website accessibility.
Policies and informational pages that people read once on their phone.
Content that changes often. Editing a web page is easier than re-exporting and re-checking a PDF.
Simple forms. A web form with proper labels usually beats a fillable PDF.

Keep a PDF when a print-ready or signable document is genuinely needed, such as a flyer, a contract or a form that has to be filed in a fixed format. In that case, publish an accessible version, and consider offering an HTML equivalent alongside it.

Avoid the temptation to just remove the link and leave the file on your server. Old PDFs remain reachable through search engines and bookmarks. Delete files you no longer need, or replace them.

Prioritizing a backlog of PDFs

If your site has dozens of old PDFs, you do not have to fix everything at once. A practical order:

Inventory. List every PDF on the site, including ones linked only from old pages.
Retire. Remove outdated files that no longer serve a purpose.
Convert. Move simple, high-traffic content (menus, hours, pricing) to HTML.
Repair. Fix the remaining documents people genuinely need, starting with the most visited.
Set a process. Require an accessibility check before any new PDF is published.

Keeping notes on what you reviewed and when is useful. See dated accessibility audit records for why a dated record helps.

Where PDFs fit in the bigger picture

Fixing PDFs alone will not make a website accessible. Navigation, forms, images, color contrast and keyboard access all matter too. The WCAG 2.1 AA checklist covers the wider set of checks. Remember also that no single step guarantees you are protected from a complaint. Accessible content reduces barriers for real people, which is the point.

For background on where PDFs and other issues appear in legal claims, see ADA website lawsuits explained. For the government's own guidance on web accessibility, see ada.gov and the W3C's PDF techniques.

To see where your web pages stand before you start on documents, you can run a free scan.

Frequently asked questions

Do PDFs on my website have to be accessible under the ADA?

The ADA does not contain a specific rule for PDFs, and courts and agencies have not all treated web content the same way. In practice, PDFs published on a site for the public are commonly evaluated against WCAG, and inaccessible ones show up in complaints. Ask an attorney how this applies to your situation.

How can I tell if my PDF is a scan?

Try to select a sentence with your cursor or search for a word in it. If nothing can be selected or found, the file is likely a picture of a page with no text layer. OCR can add one, but the result needs proofreading.

Is running OCR enough to make a PDF accessible?

No. OCR gives a scanned file selectable text, but it does not add tags, heading structure, alt text, table headers or a correct reading order. It is a first step, and the output still needs a manual review.

Should I just convert all my PDFs to web pages?

Not necessarily. HTML is usually the better choice for menus, policies and other content people read on screen. Keep PDFs for documents that genuinely need a fixed layout, and make those accessible.

Can an automated tool fix my PDFs for me?

Tools can find many problems and automate some repairs, but they cannot judge whether alt text is meaningful or a reading order makes sense. Treat automated results as a starting point and verify important documents with a screen reader.

Proof of Access provides technical accessibility assessments. We are not a law firm and nothing on this page is legal advice. If you have received a demand letter or a lawsuit, talk to an attorney.