Most accessibility programs have a blind spot, and it's sitting in your downloads folder. Teams invest real effort making their web pages perceivable and navigable — then link out to a product spec sheet, an annual report, or an application form as a PDF that a screen reader can't make sense of at all.
PDFs are documents of record: contracts, statements, menus, forms, guides. They're often the most important content you publish. And because they're created in dozens of tools by dozens of people, they're usually the least accessible thing on your site. Here's what makes a PDF accessible, and a practical workflow for closing the gap.
Why PDFs break for assistive technology
A PDF is fundamentally a set of instructions for painting ink on a page. Without extra structure, a screen reader looking at one sees exactly that — positioned text fragments with no indication of what's a heading, what's a table, what order anything should be read in, or what the images show. A scanned PDF is worse: it's just a photograph of a page, with no text at all.
The fix for this is tagging. Tags are an invisible structural layer — the PDF equivalent of semantic HTML — that tells assistive technology "this is a heading, this is a list, this is a table with these headers." The PDF/UA standard (ISO 14289) formalizes what a properly tagged, accessible PDF looks like, and it's the benchmark worth aiming for.
The five things that matter most
1. Real text, not pictures of text
If you can't select the text in your PDF, neither can a screen reader. Scanned documents need OCR (optical character recognition) at minimum, and ideally recreation from the source file.
2. Tags and a logical heading structure
Just like a web page: one title, headings in order, lists tagged as lists. A tagged 40-page report lets a screen reader user jump between sections; an untagged one forces them through it line by line — if it reads at all.
3. Reading order
Visual layout and reading order are different things. A two-column newsletter that reads left-to-right across both columns produces word salad. Reading order has to be set deliberately, especially for layouts with sidebars, pull quotes, and callout boxes.
4. Alt text for images and charts
Every informative image needs a description, and charts need their key takeaway in text — "Revenue grew 34% year over year, driven by the enterprise segment" — not just "bar chart." Decorative images should be marked as artifacts so they're skipped.
5. Accessible tables and forms
Tables need tagged header rows so a screen reader can announce "Q3, Revenue: $2.4M" instead of a bare number floating in space. Fillable forms need labeled fields, a sensible tab order, and error handling that doesn't rely on color alone.
The best remediation is often not a PDF
Before fixing a PDF, ask whether it should be one. A web page is easier to make accessible, easier to keep accessible, responsive on mobile, and easier to update. For content people actually read on screen — FAQs, guides, policies, event details — HTML is almost always the better format, with the PDF as an optional download if you need one.
Reserve PDFs for what they're genuinely good at: fixed-layout documents of record that people print, sign, or archive. A restaurant that moves its menu from a scanned PDF to a simple web page hasn't just fixed an accessibility issue — it's made the menu usable for everyone squinting at a phone.
A practical remediation workflow
You almost certainly can't fix every PDF at once, and you don't need to. Work the problem in order:
- Inventory. Find every PDF linked from your site. Most teams are surprised by the count — and by how many are outdated duplicates you can simply retire.
- Prioritize. Rank by traffic and consequence. Forms, statements, and anything required to complete a transaction come first; the 2019 press kit does not.
- Fix at the source where you can. It's far cheaper to export an accessible PDF than to repair a broken one. Word, Google Docs, and professional layout tools can all produce tagged PDFs when documents are built with real styles — heading styles, list styles, table headers, alt text — before export.
- Remediate what you can't recreate. For legacy documents with no source file, use a dedicated PDF remediation editor to add tags, set reading order, and write alt text. For large archives, remediation service providers can handle volume; keep your highest-stakes documents under your own review.
- Verify. Run an automated checker against PDF/UA, then do the test that actually matters: open the document with a screen reader and try to use it. Can you navigate by heading? Does the table make sense read aloud? Could you complete the form?
- Prevent the next backlog. Add accessible-export steps to your publishing checklist so new documents arrive accessible instead of joining the pile.
Documents are part of your site, not an exception
Visitors don't distinguish between your web pages and your downloads — a barrier is a barrier, whether it's in your navigation or your pricing sheet. The same is true of accessibility regulations, which generally apply to the documents you publish, not just the pages around them.
If you're already auditing and improving your site's pages, extending that same discipline to documents is the natural next step: find the issues, fix the ones that block real tasks, and keep new content from regressing. AllAccessible can help you build exactly that habit for your site — steady, reviewed, verifiable accessibility progress.
Get started with AllAccessible and make your whole site — pages and downloads alike — easier for everyone to use.
Frequently Asked Questions
- What makes a PDF accessible to screen readers?
- An accessible PDF needs five things: real selectable text rather than scanned images, tags with a logical heading structure, a deliberately set reading order, alt text for informative images and charts, and properly labeled tables and form fields. The PDF/UA standard (ISO 14289) formalizes these requirements and is the benchmark worth aiming for.
- What is PDF tagging?
- Tags are an invisible structural layer inside a PDF — the equivalent of semantic HTML — that tells assistive technology which content is a heading, list, or table. Without tags, a screen reader sees only positioned text fragments with no reading order, and a tagged 40-page report that lets users jump between sections becomes an untagged wall of text they must traverse line by line.
- Should I fix my PDFs or convert them to web pages?
- For content people read on screen — FAQs, guides, policies, menus, event details — a web page is almost always better: easier to make accessible, easier to keep accessible, and responsive on mobile. Reserve PDFs for fixed-layout documents of record that people print, sign, or archive, and offer them as an optional download alongside an accessible HTML version.
- How do I remediate a large backlog of PDFs?
- Inventory every PDF on your site, retire outdated duplicates, and rank the rest by traffic and consequence — forms and transaction documents first. Re-export from source files where possible since that's far cheaper than repairing a broken PDF, use a remediation editor for legacy documents, then verify with an automated PDF/UA checker plus a real screen-reader test.