How to Make a PDF Accessible: A Complete Guide
An accessible PDF is one that everyone can read — including people who use screen readers, magnifiers, or keyboard-only navigation. Most PDFs are not accessible by default: they look fine on screen but have no underlying structure for assistive technology. This guide walks through everything that goes into an accessible PDF and the fastest way to fix each piece.
Start at the source, not the PDF
The single biggest time-saver is to build accessibility into the source document before you export. A well-structured Word or InDesign file — real heading styles, proper lists, table headers, alt text on images — exports to a largely accessible PDF automatically. Fixing a finished PDF by hand is far slower than re-exporting a good source file.
Rule of thumb: if you have the editable source, fix it there and re-export. Only remediate the PDF directly when the source is gone.
The seven things every accessible PDF needs
Whether you fix the source or the PDF, the same checklist applies. Here is what an accessible PDF must have, in roughly the order of importance.
1. Tags (document structure)
Tags are the hidden structure tree that tells assistive technology what each element is — heading, paragraph, list, table, figure — and what order to read it in. An untagged PDF is essentially invisible to a screen reader. Tagging is the foundation everything else depends on.
2. Logical reading order
The order of the tags must match the order a person would read in. Multi-column layouts, sidebars, and captions frequently end up in the wrong sequence, so a screen reader reads things out of order even when the page looks correct.
3. Alternative text for images
Every meaningful image needs a short text description so screen reader users get the same information. Purely decorative images should instead be marked as artifacts so they are skipped.
4. Proper heading structure
Headings tagged H1–H6 create the outline screen reader users navigate by. Use a single top-level heading and never skip levels (H2 straight to H4 is a failure).
5. Accessible tables
Data tables need header cells tagged as TH with the correct scope, so a screen reader can announce which row and column each value belongs to. Layout tables (used only for positioning) should not be tagged as tables at all.
6. Descriptive links and labeled form fields
Links need text that describes their destination ("View the 2025 report", not "click here"). Interactive form fields each need an accessible name (the tooltip in Acrobat) and a logical tab order.
7. Document metadata
Set a real document title and the primary language. The title helps users tell documents apart; the language tells screen readers which pronunciation rules to use.
A practical workflow
- 1Run the document through an accessibility checker to get a baseline list of issues.
- 2If you have the source file, fix structure there (headings, lists, alt text, table headers) and re-export.
- 3For PDF-only documents, auto-tag in Acrobat Pro, then correct reading order and element types.
- 4Add alt text to meaningful images; mark decorative content as artifacts.
- 5Fix tables, links, and form fields.
- 6Set the document title and language.
- 7Re-check, then test with a real screen reader (NVDA is free) to confirm it makes sense aurally.
How to verify compliance
Automated checkers catch the machine-testable issues — missing tags, missing alt text, untitled documents — and are the right first and last step. But some requirements (is the alt text actually meaningful? does the reading order make sense?) need a human check. Use an automated checker to find the bulk of issues fast, then spot-check with a screen reader.
You can check any PDF for free on this site — upload a file and you will get a categorized list of every PDF/UA and WCAG 2.1 AA issue, with the severity of each.