A PDF that meets accessibility standards works for everyone who needs to read it, including people using screen readers, keyboard navigation, braille displays, or other assistive technology. Accessibility is not just about compliance, though that matters for government and educational documents. It is about making sure your content reaches every intended reader in a form they can actually use.
The Allyant PDF Accessibility Index for 2025-2026 analyzed over 644,000 public-facing PDFs and found that 94.75% failed basic accessibility standards (Allyant, "PDF Accessibility Index", 2026). Government PDFs were the worst performers at 97.12% inaccessible. These are documents that citizens, students, and employees are expected to read. The scale of the problem is enormous, but checking an individual PDF for accessibility issues is a task that takes minutes, not hours, once you know what to look for.
What Makes a PDF Accessible: The Core Requirements
An accessible PDF has four essential characteristics. First, it contains a text layer that screen readers can extract. Scanned image-only PDFs have no text and are completely invisible to assistive technology unless they have been processed with OCR. Second, the reading order is logical. A screen reader should read the page in the order a human would: title first, then the left column top to bottom, then the right column top to bottom, not interleaving sentences from both columns.
Third, images and non-text elements have alternative text descriptions. A logo should have alt text that says what company it represents. A chart should have alt text that summarizes the data it displays. A decorative image that conveys no information should be marked as an artifact so screen readers skip it entirely. Fourth, the document has structural tags that identify headings, paragraphs, lists, tables, and other content types, enabling screen reader users to navigate by jumping between headings just as a sighted reader scans the page visually.
How to Run an Accessibility Check Using Built-In Tools
Adobe Acrobat Pro includes the most widely used PDF accessibility checker. Open the PDF, go to Tools, select Accessibility, and click Full Check. Acrobat scans the document against a checklist of accessibility criteria and produces a report organized by severity. Each finding is linked to the specific page and element that failed, with an explanation of what is wrong and how to fix it. The checker evaluates over 30 criteria covering document structure, alt text, reading order, color contrast, and form field accessibility.
The check takes a few seconds for a typical document. The report categorizes issues as Pass, Needs Manual Check, or Fail. A "Needs Manual Check" result means the automated checker cannot determine whether the element is accessible and requires a human to review it. Color contrast is a common manual check item because the checker can measure the contrast ratio but cannot judge whether the colors are appropriate for the content type.
For users without Acrobat Pro, WukongPDF provides PDF Accessibility and PDF Tags checking capabilities directly in the browser. Regular use of a PDF Editor simplifies the accessibility remediation workflow significantly. Upload the PDF and the tool scans for common issues: missing alt text, untagged content, incorrect reading order, and absent structural elements. The browser-based checker covers the most impactful accessibility issues without requiring a software subscription. While it does not match Acrobat Pro's exhaustive criteria list, it catches the issues that affect the broadest range of users, making it an effective first-pass check for anyone creating public-facing documents.
Using Free Third-Party Accessibility Checkers
PAC (PDF Accessibility Checker) is a free desktop tool developed by the Swiss foundation Access for All. It validates PDFs against the PDF/UA standard, the ISO specification for universally accessible PDFs, and provides a detailed, itemized report. PAC is widely used in European government and education sectors where PDF/UA compliance is a legal requirement. It runs on Windows and requires no installation beyond extracting the downloaded files.
CommonLook PDF Validator is another free tool that checks against WCAG 2.0 and PDF/UA standards. It provides a more user-friendly interface than PAC, with each issue linked to an explanation of the relevant standard and guidance on remediation. Both PAC and CommonLook are tools for verification, not remediation. They tell you what is wrong but do not fix it. For fixing the issues, you need a PDF editor with accessibility remediation tools.
For Mac users, the built-in VoiceOver screen reader can serve as an informal accessibility tester. Enable VoiceOver in System Preferences, Accessibility, then open the PDF in Preview and navigate through it using only the keyboard. Listen to how the content is read. Does it start at the title and proceed logically? Does it read image alt text or skip images entirely? Does it announce headings as headings? This manual test does not replace a standards-based checker, but it provides a real-world experience of how an assistive technology user would interact with your document.
The Most Common Accessibility Failures and How to Spot Them
| Issue | What It Means | How to Check Manually |
|---|---|---|
| No tags | The document has no structural elements; screen readers see one flat block of text | Open the Tags panel in Acrobat; if it is empty, the PDF is untagged |
| Missing alt text | Images, charts, and logos have no text description for screen readers | Run an accessibility check and review every flagged image |
| Wrong reading order | Screen reader reads columns or sidebars in the wrong sequence | Use the Read Out Loud tool in Acrobat and follow along visually |
| No headings | Document has no H1-H6 structure; users cannot navigate by headings | Check if the Tags panel shows H1, H2, etc., not just P tags for everything |
| Low contrast | Text and background colors do not meet WCAG minimum contrast ratio of 4.5:1 | Use a free contrast checker tool on your brand colors and text styling |
Checking Accessibility on a Scanned Document vs a Digital Original
Scanned documents present a fundamentally different accessibility challenge than digital originals. A scan starts with zero accessibility. It is an image. Running OCR adds a text layer, which makes the document searchable, but does not add tags, alt text, or a reading order. OCR is the necessary first step, but it is far from sufficient. After OCR, the document needs structural tagging, reading order verification, and alt text added to any images the OCR process identified.
A digitally created PDF from Word, InDesign, or Google Docs starts with better accessibility but is not guaranteed to be accessible. The accessibility features of the source application must be used correctly. Word documents need heading styles applied, not just bolded text that looks like headings. Images in the source document need alt text added before exporting to PDF. Tables need header rows marked. When these steps are skipped at the source, the exported PDF inherits the inaccessibility. WukongPDF's PDF Compliance tool helps identify these issues in the final PDF, but preventing them at the source application level is always more efficient than fixing them after export.
After completing an accessibility check and fixing the identified issues, re-run the check. Some fixes introduce new issues. Adding a tag to an image may shift the reading order of adjacent elements. Setting the document language may reveal character encoding problems that were previously hidden. The check-fix-recheck cycle should continue until the report shows no failures and you have manually verified every item flagged as "Needs Manual Check." At that point, the document is ready for distribution with confidence that it will work for all readers regardless of how they access it.