PDF Accessibility Guide: Tags, Alt Text and Screen Reader Tips
Most PDFs fail screen readers by default. Here's how to add tags, alt text and correct reading order to fix that.
Open any random PDF on the web and run a screen reader on it. Odds are it either reads the content in scrambled order, skips images entirely, or announces "unlabeled graphic" every few seconds. This is the accessibility gap that catches most document authors off guard: saving to PDF doesn't preserve accessibility — it actively strips it unless you take deliberate steps. This guide covers what makes a PDF accessible, what the law says you need to do, and the practical tools to get there.
Why PDFs Aren't Automatically Accessible
A PDF is fundamentally a visual format. It describes where ink goes on a page — coordinates, fonts, colors. It says nothing about what any of that ink means. A heading that looks like a heading is, structurally, just large bold text at specific coordinates. A screen reader doesn't know it's a heading unless a tag tells it so.
When a PDF has no tags, screen readers try to reconstruct reading order from the raw content stream. That stream reflects the order the designer placed elements on the page, not the order a reader should encounter them. Multi-column layouts, sidebars, and tables frequently produce nonsense output: a screen reader might read the left column, then the right column, then the header, then a footer caption — all as one continuous paragraph.
The numbers illustrate why this matters. Adobe Acrobat Pro's high subscription cost (85% of users cite "can't edit without Acrobat" as a top pain point) pushes document authors toward tools that produce PDF output with no accessibility checks built in. Most office suites, design tools, and PDF printers produce untagged output by default. The result is a web full of PDFs that are usable only if you can see them.
Even PDFs with tags often have gaps: images without alt text, tables without header cells, forms without field labels, and a document language that's never declared. Each of these is a distinct failure mode for assistive technology.
Legal Requirements: Section 508, ADA and WCAG
PDF accessibility isn't optional if your organization publishes documents for public use. Several overlapping legal frameworks cover it.
Section 508 of the US Rehabilitation Act requires federal agencies and organizations that receive federal funding to make electronic content — including PDFs — accessible. Section 508 was updated in 2018 to align with WCAG 2.0 Level AA, so the technical standards are now shared.
The ADA (Americans with Disabilities Act) covers private businesses open to the public. Courts have consistently extended ADA Title III to websites and digital documents. PDF accessibility lawsuits are no longer rare; higher education institutions, healthcare providers, and retailers have all faced enforcement actions.
WCAG 2.1 (Web Content Accessibility Guidelines) is the international benchmark. Success criteria that apply to PDFs include: providing text alternatives for non-text content (1.1.1), ensuring content can be presented in a meaningful sequence (1.3.2), and making sure there's sufficient color contrast (1.4.3). PDF/UA (ISO 14289) is the PDF-specific standard that operationalizes these rules.
The EU Web Accessibility Directive and European Accessibility Act extend similar obligations to public-sector bodies and many private companies operating in EU member states, with the EAA phasing in enforcement through 2025 and 2026.
Practically speaking: if you publish PDFs for any external audience — government, education, healthcare, finance — treat accessibility compliance as baseline, not bonus.
Key Accessibility Elements Every PDF Needs
Getting a PDF to pass an accessibility check comes down to six structural components.
Document tags are the foundation. A tagged PDF contains a logical tree — <Document>, <Section>, <P>, <H1> through <H6>, <Table>, <Figure>, and so on — that maps to the visual content. Without tags, everything else is moot.
Heading hierarchy gives screen reader users the ability to navigate by landmark. A document with three levels of headings should use <H1>, <H2>, and <H3> in order — not visually styling paragraphs to look like headings while tagging them as <P>.
Alt text for images is required for any image that conveys meaning. Decorative images (dividers, background textures) should be tagged as <Artifact> so screen readers skip them. Informative images — charts, diagrams, photos of products — need a concise description of what the image communicates, not just what it depicts. "Graph showing sales rising 40% Q1 to Q4 2024" is more useful than "bar chart."
Reading order must match the logical sequence of the document. When tags exist but reading order is wrong, the experience is nearly as broken as having no tags at all. In a two-column layout, reading order must flow through column one completely before starting column two.
Table headers need the <TH> tag with the correct scope attribute (row, col, or both). A table where header cells are tagged as <TD> gives screen reader users no way to know which column or row each cell belongs to.
Form field labels must be programmatically associated with their fields. A PDF form where labels are just text positioned near input boxes — but not linked to them — is unusable for screen reader users filling in forms.
How to Check PDF Accessibility
Two tools are worth knowing: one from Adobe, one free.
Adobe Acrobat's Accessibility Checker (available in Acrobat Pro and the free Acrobat Reader with limited functionality) runs automated checks against PDF/UA and WCAG criteria. In Acrobat Pro, go to All Tools → Prepare for Accessibility → Accessibility Check. The results panel lists failures by category — tagging, reading order, images, forms, tables — with links into the document. It also provides a "Reading Order" tool that lets you visually inspect and reorder the tag tree.
PAC 2024 (PDF Accessibility Checker) is a free Windows application from the Swiss organization Access for All. It's widely considered more thorough than Acrobat's built-in checker, particularly for PDF/UA compliance. PAC generates a detailed report showing exactly which PDF/UA and WCAG criteria each failure maps to. Download it at pdfua.foundation.
Neither tool catches everything. Automated checkers reliably find structural issues (missing tags, untagged images, missing document language) but can't judge whether alt text is good — only whether it exists. Manual review with an actual screen reader (NVDA on Windows is free; VoiceOver ships with macOS and iOS) is the only way to verify the user experience end to end.
A useful workflow: run PAC 2024 first to get a complete list of structural failures, fix them, then do a manual read-through with NVDA to catch content-level issues.
Adding Alt Text to Images in PDFs
Alt text is the most common accessibility gap in real-world PDFs, and fortunately it's one of the easier things to fix.
In Adobe Acrobat Pro, right-click any image in the document → Edit Alt Text → type your description. For decorative images, check "Decorative figure" instead of writing text.
In Microsoft Word (before exporting to PDF), right-click any image → Edit Alt Text. Word's export to PDF preserves alt text as <Figure> tags — provided you use Save As → PDF (not Print to PDF, which strips all accessibility data).
In Google Docs, right-click an image → Alt text → add title and description. Google's Download as PDF also preserves these tags.
For PDFs you receive without source files, remediation has to happen in Acrobat Pro or a specialist tool like Foxit PDF Editor. The "Fix Reading Order" panel in Acrobat lets you click each figure and assign alt text directly in the tag tree.
Mozilla recently added automatic AI-generated alt text to PDF.js (the engine behind Firefox's built-in PDF viewer), which surfaces suggested descriptions for untagged images as you view them. This is an emerging browser-level accessibility assist — not a replacement for authoring correctly, but a meaningful safety net for readers encountering poorly tagged documents.
For other PDF editing tasks — rearranging pages, removing sensitive content, or adjusting layout before you run accessibility remediation — OnlinePDFEdits lets you edit text, images, and layout directly in a browser without installing anything. Once the layout is correct, you can open the resulting PDF in Acrobat for tag remediation.
Remediation Workflow: Fixing Existing PDFs vs. Starting Clean
There are two situations: you have a library of existing PDFs to fix, or you're creating new documents going forward.
Fixing existing PDFs is called remediation. For large volumes, it's labor-intensive: each document needs tags applied, reading order checked, images described, and forms labeled. Automated tools can apply tags to untagged PDFs (Acrobat's "Add Tags to Document" function), but the results need manual review — auto-tagging frequently gets heading levels wrong and misclassifies decorative elements.
Prioritize your remediation backlog by impact: documents that get the most traffic, forms users need to submit, and content required by law (annual reports, public notices, required disclosures) should come first. Use PAC 2024 to triage which documents have the most failures.
Starting clean is much cheaper. A few habits eliminate most accessibility debt:
- Use heading styles in Word/Google Docs, not manual font sizing. Styles export as heading tags.
- Add alt text before exporting. It takes ten seconds per image in Word.
- Set the document language. In Word: File → Info → Properties → Language. This exports as the PDF's language declaration, which screen readers use to select the right voice and pronunciation rules.
- Add a document title. File → Properties → Title. It's the first thing a screen reader announces when opening the document.
- Export as PDF, never print to PDF. Print-to-PDF drivers produce flat, untagged output every time.
For quick wins on a document you need to make accessible today: add the document title, set the language in Acrobat (File → Properties → Description), and run "Add Tags to Document." Those three steps move a completely inaccessible PDF to partial compliance in under five minutes, giving screen readers a structure to work with even if it needs refinement.
If you need to reorganize pages or remove pages before starting the accessibility workflow, handle the structural edits first — accessibility remediation on a document whose page order will change is work you'll have to redo. Similarly, if you're working with a large PDF that needs to be broken into separate documents, extract the pages you need before tagging.
See also our guide on editing PDFs without Adobe Acrobat if you're looking for a starting point for layout edits before remediation.
FAQ
Does saving a Word document as a PDF make it automatically accessible?
Not automatically, but it can if you've used Word correctly. You need heading styles (not manual formatting), alt text on all images, proper table headers, and you must use File → Save As → PDF rather than Print to PDF. Print-to-PDF strips all accessibility structure. Even a correctly saved Word PDF should be checked with PAC 2024 before publishing, since some tag structures export imperfectly.
What's the difference between PDF/UA and WCAG for PDFs?
WCAG (Web Content Accessibility Guidelines) is the broader standard covering web content including PDFs. PDF/UA (ISO 14289) is a PDF-specific standard that operationalizes WCAG requirements in PDF technical terms — it specifies exactly how tags, reading order, alt text, and other elements must be structured in the PDF format. In practice, a PDF that passes PDF/UA also satisfies WCAG 1.3.2, 1.1.1, and related success criteria. PAC 2024 checks against both standards simultaneously.
Can I make a scanned PDF accessible?
Yes, but it requires an extra step. A scanned PDF is an image of a page with no text content — screen readers see nothing at all. You first need to run OCR (Optical Character Recognition) to convert the image to selectable text. After OCR, the PDF has text content, but it still needs tags, alt text, and reading order applied. Adobe Acrobat Pro's OCR output is already tagged. Free OCR tools typically produce untagged text that needs manual remediation afterward.
Is a PDF accessibility checker enough to confirm compliance?
No. Automated checkers like PAC 2024 and Acrobat's built-in tool catch structural failures reliably — missing tags, absent document language, untagged images — but they can't evaluate whether alt text is accurate, whether heading levels make logical sense, or whether the reading order produces a coherent experience. Plan for manual review with a screen reader (NVDA on Windows, VoiceOver on Mac) on any document you need to certify as compliant. Budget roughly 20-30 minutes per document for a thorough manual check after automated fixes are applied.
