How to test and fix PDF accessibility
How to test PDF accessibility with a checker and manual review, fix common tagging and structure issues, and build accessible PDFs from the start.
PDF Accessibility Checker: Test Your PDFs
Checking a PDF for accessibility means looking beyond how the document appears visually. Missing tags, incorrect reading order, unlabeled forms, and absent alt text can make a PDF difficult or impossible to use with assistive technology.
A PDF accessibility checker can identify many of these issues automatically, but some problems still require manual review. This guide explains how to check a PDF, understand the results, fix common issues, and create more accessible PDFs from the start.
Key takeaways
An accessible PDF has tagged structure, a logical reading order, alt text, and labeled forms, not just readable-looking text.
The best way to check PDF accessibility is to combine an automated checker with manual testing.
Automated PDF accessibility checkers catch objective issues like missing tags or alt text, but they can't judge whether alt text is accurate or reading order makes sense.
WCAG's success criteria are commonly applied to PDFs as well as web pages; PDF/UA adds PDF-specific technical rules on top of that.
Section 508 requires WCAG 2.0 Level AA conformance for federal PDFs, and federal testing shows most agency PDFs still fall short.
Building accessibility into your source document is faster and cheaper than remediating a finished PDF.
How to check a PDF for accessibility
The best way to check PDF accessibility is to combine an automated PDF accessibility checker with manual testing.
Run an automated check. Adobe Acrobat Pro's built-in “Check for Accessibility” tool, PAC 2024 (a free Windows tool built specifically for PDF/UA conformance), or a browser-based checker like axesCheck will flag objective issues: missing tags, missing alt text, untagged tables, undefined language, and more.
Review the tag tree. Open the tags panel and confirm the structure matches the visual layout: headings nest correctly, tables have header rows tagged, lists are marked as lists.
Check the reading order. Use the checker's reading order tool, or simply tab through the document, to confirm content is announced in a sensible sequence.
Test with a screen reader. Even a quick pass with a free screen reader (like NVDA on Windows or VoiceOver on Mac) will surface problems automated tools miss, like alt text that doesn't describe what's actually in an image.
Check forms and links. Confirm form fields have labels and instructions, and that links describe their destination rather than reading as “click here.”
What does a PDF accessibility checker test?
Most PDF accessibility checkers organize results into a handful of categories:
Document properties (title, language, tags)
Page content (reading order, tab order)
Forms (field labels)
Alternate text (images and figures)
Tables (headers and structure)
Lists
Headings (proper nesting)
Each issue is typically flagged as passed, failed, or “needs manual check,” because some criteria, like whether alt text is actually accurate, can't be judged by software alone.
What can't a PDF accessibility checker detect?
Automated checkers reliably catch technical issues such as missing tags, missing alt text, and undefined document language. They can't reliably judge whether alt text is meaningful, whether reading order actually makes sense, or whether the document works well with assistive technology in practice.
A passing automated report is a useful starting point, not proof that a PDF is fully accessible or compliant with a specific legal standard.
What is an accessible PDF?
An accessible PDF is a document structured so people using assistive technologies, such as screen readers, screen magnifiers, voice control, and keyboard navigation, can access and understand its content. That means tagged headings, a logical reading order, alt text for meaningful images, labeled form fields, and a defined document language and title, not just text that looks correct on screen.
A PDF can look completely normal and still fail this test. A page created by scanning a printed document, for example, may contain no real text at all, just a picture of text. To a screen reader, that page is blank.
Accessible PDFs typically include a logical tag structure, correct reading order, meaningful alt text, labeled form fields, selectable text, appropriate color contrast, and document metadata such as language and title.
Missing or incorrectly configured versions of these elements are among the most common causes of inaccessible PDFs. For example, a PDF exported from a two-column layout without proper tagging often reads to a screen reader as one continuous line that jumps between columns mid-sentence.
PDF accessibility sits inside the broader field of digital accessibility, which also covers websites, mobile apps, and other digital content, and shares many of the same underlying principles defined by WCAG.
PDF accessibility checklist: what to check before publishing
Most public-facing PDFs don't pass a basic accessibility check today. One 2026 benchmark study found that 94.75% of the PDFs it scanned, across more than 644,000 documents, failed to meet WCAG 2.2 standards. Use the checklist below before publishing any PDF.
Check | What to confirm |
|---|---|
Document title | A descriptive title is set in document properties, not just the filename |
Document language | The primary language is specified in document properties |
Tags | The document has a complete tag tree that matches the visual structure |
Reading order | Content is announced in a logical sequence, matching the intended reading flow |
Headings | Headings are tagged and nested in order (H1, then H2, then H3, without skipping levels) |
Alt text | Meaningful images and charts have accurate alt text; decorative images are marked as artifacts |
Tables | Tables have tagged header rows and cells are associated with the correct headers |
Lists | Bulleted and numbered content is tagged as a list, not just formatted to look like one |
Links | Link text describes the destination, not “click here” or a raw URL |
Forms | Every form field has a label, and instructions are provided where needed |
Color contrast | Text meets a minimum 4.5:1 contrast ratio against its background |
Color-only meaning | Information isn’t conveyed through color alone (e.g., red text without another indicator) |
Text vs. images of text | Body text is real, selectable text, not a scanned image |
How to fix PDF accessibility issues
Once a checker or manual review flags issues, fixing them is a structured process, usually done in Adobe Acrobat Pro or a similar tool with accessibility editing features. Start by triaging: prioritize documents with high traffic or time-sensitive information, such as forms, applications, or public notices, over low-traffic archival files, and separate issues that are easier to fix by re-exporting from the original source file than by patching the finished PDF.
Fix tagging problems. Use the tags panel to add missing tags, correct mis-tagged elements, and make sure the tag tree mirrors the visual layout.
Add and edit alt text. Write alt text that describes the content and purpose of each meaningful image; mark purely decorative images as artifacts so screen readers skip them.
Correct reading order. Reorder tags or use the reading order tool to fix sequences that don't match the intended flow.
Tag tables and lists properly. Confirm header rows are tagged as headers and associated with data cells; confirm lists use list tags rather than manual bullet characters.
Label form fields. Add descriptive labels and tab order to every interactive field.
Set document language and title. Add these in document properties if missing.
For scanned documents, run OCR. Optical character recognition adds a text layer, but the output still needs tagging and review afterward, OCR alone does not make a scanned PDF accessible.
Re-run the checker and do a manual pass to confirm the fixes worked, then build the fix into your publishing process so the same issue doesn't reappear in your next document.
This kind of structural, document-level correction is what's known as accessibility remediation: permanent fixes to the underlying content, not a workaround layered on top of it.
If your organization is also working on broader website accessibility, Clym's accessibility testing and audit tools can help evaluate WCAG conformance across your site.
How to make a PDF accessible from the start
Remediating finished PDFs is slower and more expensive than building accessibility in from the beginning. If your team regularly produces PDFs, from Word, PowerPoint, or InDesign, accessibility should start in the source file.
Use built-in styles, not manual formatting. Apply real Heading 1, Heading 2, and body text styles in your word processor instead of just making text bold and bigger. These styles carry over as tags when you export to PDF.
Add alt text in the source document. Most authoring tools let you add alt text to images directly, and it will carry through to the exported PDF.
Use real tables and lists, not tab-spaced columns or manually typed bullet characters.
Export with tagging enabled. When exporting to PDF, choose the “accessible” or “tagged PDF” export option rather than a flat print-to-PDF setting.
Set the document title and language in the source file's properties before exporting.
Run a check before publishing, every time, even for documents built from an accessible template.
Building this into your publishing workflow, rather than treating it as a one-time cleanup project, is what keeps a document library accessible over time instead of drifting back into non-conformance.
PDF accessibility and WCAG
WCAG is written primarily for web content, but its success criteria, such as text alternatives for images, meaningful sequence, and sufficient color contrast, are commonly applied to non-web documents like PDFs as well. The W3C has published guidance on applying WCAG to non-web documents for this reason.
When a law or standard requires WCAG conformance for an organization's digital content, that expectation typically extends to the PDFs it publishes, not just its web pages, particularly where the law explicitly names electronic documents as in scope. In practice, the same WCAG 2.2 checklist your team uses for website reviews is a reasonable starting framework for reviewing PDFs too, keeping in mind that PDFs have their own structural quirks, like tag trees and reading order, that don't map perfectly onto web markup.
What is PDF/UA?
PDF/UA, short for PDF/Universal Accessibility and formally published as ISO 14289, is a technical standard written specifically for PDFs. It defines exactly how tagging, reading order, and metadata must be structured inside the file itself, more prescriptive and PDF-specific than WCAG's broader, format-independent principles.
The two standards complement each other. A PDF can satisfy WCAG's content-level principles while still failing PDF/UA's stricter technical rules, and organizations aiming for the most robust PDF accessibility typically target both. PAC 2024 is built specifically to test PDF/UA conformance, which is why it's often run alongside a WCAG-focused checker.
Section 508 and PDF accessibility
Section 508 requires U.S. federal agencies to make the electronic content they develop, procure, maintain, or use accessible, including PDFs. The current Section 508 standards incorporate WCAG 2.0 Level A and AA requirements for electronic documents. Vendors supplying technology to federal agencies may also face accessibility requirements through federal procurement contracts.
PDF accessibility remains a significant challenge. A joint DOJ and General Services Administration assessment found that PDFs represented 77% of the most-downloaded files across federal agencies, but only 20% were fully conformant. Automated checking can help identify accessibility issues, but it should be combined with manual review and remediation rather than treated as proof of compliance.
How Clym fits into a broader accessibility program
PDF accessibility is one piece of a larger picture that includes your website accessibility, forms, and other digital touchpoints. If your organization is already working toward WCAG or ADA conformance for its website, it's worth treating document accessibility as part of the same program rather than a separate afterthought.
An accessibility statement is a natural place to note how your organization handles accessible documents alongside your website commitments. Clym's tools are built for web content, they don't check or remediate PDFs directly, but they're part of the same overall accessibility strategy that document accessibility belongs to.
Conclusion
Checking PDF accessibility requires more than running an automated tool. A checker can flag missing tags, alt text, and metadata, but reading order and content quality still need manual review.
The most reliable approach is to build accessibility into your source documents, check every PDF before publishing, and fix issues that affect people using assistive technology, rather than treating accessibility as a one-time cleanup project.
Frequently asked questions
An accessible PDF is a document structured with tags, a logical reading order, alt text, and labeled forms so that people using screen readers or other assistive technology can access its content, not just a document that looks correct visually.
Run an automated checker like Adobe Acrobat Pro's accessibility check or PAC 2024, then manually review the tag tree, reading order, and alt text, ideally testing with a screen reader, since automated tools alone can't confirm content quality.
Most checkers test document properties, tags, reading order, alt text, tables, lists, headings, and forms, flagging each issue as passed, failed, or needing manual review.
No. Automated checkers catch objective technical issues like missing tags or alt text, but they can't confirm alt text is meaningful or that reading order makes sense, so a passing report isn't a guarantee of accessibility or legal compliance.
Use built-in heading styles, real tables and lists, and alt text in your source document, then export with tagging enabled rather than relying entirely on remediation after the fact.
PDF tags are hidden structural markers that tell assistive technology what each piece of content is, a heading, a table, a list, and in what order to read it. Without accurate tags, a screen reader can't interpret the document's structure.
PDF/UA (ISO 14289) is a technical standard specific to PDFs that defines exactly how tagging, reading order, and metadata must be structured, complementing WCAG's broader, format-independent accessibility principles.
WCAG's success criteria are commonly applied to PDFs as well as web pages, and most accessibility laws that reference WCAG for websites extend the same expectation to the documents an organization publishes.
Run OCR to add a text layer, then tag the resulting document, since OCR alone restores text but does not add the structure, reading order, or alt text needed for full accessibility.
Compliance Content Manager | CIPP/E (IAPP) | CPACC (IAAP)
Alex is a Compliance Content Manager at Clym, where he researches and writes about everything related to data privacy and web accessibility compliance for businesses, helping them stay informed on their compliance needs and spreading awareness about making the web safer and more inclusive. When he's not writing about compliance, Alex has his nose in a book or is hiking in the great outdoors.
