Accessibility lives in the tag layer
Every PDF has two layers: the visual page you see, and a tag tree underneath that describes what the content actually is. Screen readers read the tags, not the page. Acrobat Pro is the tool for inspecting and fixing that tag layer, which is why it is where most PDF accessibility work is finished and verified.
This guide is part of our wider document accessibility guide. Most PDFs arrive here from another tool, so read it alongside the Word, PowerPoint and InDesign guides. The cheapest fixes happen in the source, and Acrobat is where you complete and confirm the result.
1. Why a print mindset breaks PDFs
The PDF format was invented to be a faithful, fixed picture of a printed page, and that heritage is the root of most accessibility problems. When people think of a PDF as final print output, they reach for the habits that destroy structure: they scan a paper document to an image, they use Print to PDF, or they flatten everything so it "looks right everywhere". Each of those produces a file that looks like a document and contains no document structure at all.
Accessibility does not live in the visual page. It lives in the tag layer underneath, the same headings, lists, tables and figures a screen reader needs. A print-first PDF has an empty or broken tag layer, so to assistive technology it is a blank or a scramble, no matter how crisp it looks on screen.
The shift: stop thinking of a PDF as a printout and start thinking of it as a structured document that happens to have a fixed layout. The goal is a tagged file whose tag tree matches what the eye sees.
2. Common PDF pitfalls to look for
- The PDF is untagged. Check File > Properties > the Tagged PDF field. If it says No, nothing below works until you tag it.
- It is a scanned image with no real text, so there is nothing for a screen reader to read until you run OCR.
- Auto-tagging left the structure wrong: headings tagged as paragraphs, lists broken, figures missed.
- Reading order does not match the visual order, especially in multi-column and designed layouts.
- Tables without header cells, so screen readers cannot announce which row and column a value belongs to.
- Figures with no alt text, or decorative images not marked as artifacts.
- Form fields with no labels or an illogical tab order.
- No document title or language set, so the file announces its file name and may use the wrong pronunciation.
- Relying on the Acrobat checker alone and assuming a clean result means the PDF is accessible.
Tags are the structure. The tag tree is where you inspect and fix it. In current Acrobat Pro the accessibility tools are grouped under All tools > Prepare for accessibility (in older versions, the Accessibility tool in the Tools pane). The governing criterion is 1.3.1 Info and Relationships.
- If the document is untagged, run Autotag Document as a starting point, never as the finished product.
- Open the Tags panel and walk the tree, confirming headings (H1, H2, H3), lists (L, LI), tables and figures are tagged correctly.
- Fix mis-tagged content: change a paragraph that should be a heading, group list items, and remove empty or junk tags.
- Mark decorative content as an artifact so it is skipped.
4. Reading order
Reading order is the sequence assistive technology follows, and it must match the logical visual order. The criteria are 1.3.2 Meaningful Sequence and 2.4.3 Focus Order.
- Use the Reading Order tool to review and reorder content regions, then confirm against the Tags panel, which is the definitive order.
- Pay close attention to pull-quotes, sidebars, multi-column text and floating images, the usual sources of out-of-order reading.
- Use Reflow view (View > Zoom > Reflow) as a quick sanity check on the order.
- Always confirm by reading the document with a screen reader, not just by trusting the panels.
5. Tables and headers
Tables are where auto-tagging most often falls short, and where the Acrobat-specific work really matters. Structure is again 1.3.1 Info and Relationships.
- Confirm the table is tagged with real Table, TR, TH and TD tags, not as a set of paragraphs.
- Use the Table Editor to set header cells as TH and assign scope (row or column) so relationships are announced correctly.
- Fix merged and split cells, which frequently break under auto-tagging.
- For very complex tables, consider whether splitting them or providing a simpler text summary would serve readers better.
Figures need alt text, and interactive PDFs need properly labelled fields. See 1.1.1 Non-text Content, 3.3.2 Labels or Instructions and 4.1.2 Name, Role, Value.
- Add alt text to every meaningful figure via the Tags panel or the Set Alternate Text tool. Describe purpose, not appearance.
- Mark decorative images as artifacts so they are not announced.
- For forms, give every field a tooltip that acts as its label, set a logical tab order, and group related fields.
- Write clear instructions and error messages, and make sure the form can be completed with a keyboard alone.
7. Language, title and metadata
Small settings that screen readers depend on. See 3.1.1 Language of Page.
- Set the document language in File > Properties > Advanced (for example English (Australia)), and tag any passages in other languages.
- Set a meaningful document title in File > Properties > Description, then set Show Document Title in File > Properties > Initial View so the title, not the file name, is announced.
- Add bookmarks for long documents so readers can navigate by section.
8. Scanned PDFs and OCR
A scanned PDF is an image of a page with no real text. It needs the most work of all.
- Run OCR (Scan & OCR > Recognise Text) to turn the image into real, selectable text.
- Then tag the document, verify the reading order, and add alt text to any figures, exactly as for any other PDF.
- Check the OCR output for recognition errors, which are common with low-quality scans.
- For large or complex scans, regenerating the document from its original source is almost always faster and more reliable than remediating the scan. See document remediation.
9. Verifying with the checker and PAC
Verification is two layers: Acrobat's own check, and an independent PDF/UA check, plus a human pass. We cover the wider trade-off in manual vs automated accessibility testing.
- Run Acrobat's Check for accessibility and resolve every issue it raises.
- Run PAC (PDF Accessibility Checker), the free tool used to test PDF/UA conformance, which catches issues Acrobat does not.
- Read the document end to end with a screen reader such as NVDA or VoiceOver. This is the only way to confirm the experience is actually right.
- Remember that a clean checker result is necessary but not sufficient. Meaningful alt text, logical reading order and correct headings all need human judgement.
For procurement, you may also need a formal VPAT or Accessibility Conformance Report, and for full independence an audit and compliance engagement with a re-test.
10. Common questions about PDF accessibility
What makes a PDF accessible?
A tagged PDF whose tag tree matches the content: real headings, lists and tables, figures with meaningful alt text, verified reading order, language and title set, and labelled form fields. The technical standard is PDF/UA and the content standard is WCAG 2.2 Level AA.
Can I make a scanned PDF accessible?
Only with real work. Run OCR to create real text, then tag, verify reading order and add alt text. For large or complex scans, rebuilding from the source is usually cheaper and more reliable.
Is the Acrobat Accessibility Checker enough?
No. It confirms certain tags and properties exist but cannot judge reading order, alt-text quality or correct heading use. Add the PAC PDF/UA checker, a manual tag review and a screen reader read-through.
Should I fix the PDF or the source file?
Fix the source wherever you can. A clean Word or InDesign file produces a far better PDF and saves repeated remediation. Use Acrobat to finish and verify, not to rebuild structure that should have come from the source.