How to Check a PDF for Accessibility: Complete Guide

94.75% of public-facing PDFs were found to be inaccessible in a widely used benchmark report released in 2026, with only 5.25% reaching a baseline level of usability. The results were even worse in government, where 97.12% were inaccessible, and education, where 98.01% failed the benchmark's accessibility assessment. The 2026 industry report makes one point difficult to ignore: knowing how to check a PDF for accessibility requires more than uploading it to a scanner and accepting a pass result.

TLDR

A reliable PDF accessibility review has two layers:

1. Automated validation, using tools such as Adobe Acrobat Pro, PAC 2026, PDF4WCAG, or batch-oriented validators, to identify detectable structural and metadata failures.
2. Manual and assistive technology testing, including tag-tree inspection, reading-order review, keyboard navigation, and screen-reader testing with tools such as NVDA, JAWS, or VoiceOver.

Automated tools can identify missing tags, document language problems, untagged annotations, and some form-field defects. They can't reliably determine whether alternative text is meaningful, whether a table makes sense when read aloud, or whether a multi-column document follows a logical sequence.

Use PDF/UA and WCAG 2.2 as standards anchors, prioritize documents by audience and risk, and record every finding in a governance-ready audit report. A PDF that passes a machine scan but confuses a screen-reader user hasn't passed a meaningful accessibility review.

Why Most PDF Accessibility Checks Miss the Mark

The scale of PDF inaccessibility changes how teams should approach remediation. If almost every public-facing PDF in a broad industry benchmark fails at least one checkpoint, the problem isn't a few careless files. It's usually a production and governance issue spread across templates, authoring tools, export settings, scanned documents, and inherited content libraries.

Automated checkers are valuable because they identify defects consistently and quickly. They can inspect whether a document has tags, whether a language property exists, and whether certain required objects are present. But those checks usually examine the document's technical structure, not the meaning conveyed by that structure.

A PDF can contain a tag tree and still provide a poor experience. A heading may be tagged as a paragraph, a paragraph may appear before the heading it introduces, or a decorative image may be announced as important content. A table may contain header tags while failing to associate those headers with the correct data cells. These failures can leave users with a document that technically contains accessibility features but doesn't communicate reliably.

The two-layer model

The first layer is machine-verifiable validation. It provides a repeatable baseline and exposes structural failures that are easy to overlook during a visual review. The second layer is human verification, which examines whether the structure represents the document's intended meaning and whether assistive technology users can complete realistic tasks.

That distinction aligns with the formal history of PDF accessibility. PDF/UA-1 is defined by ISO 14289-1, while current checking workflows may also assess WCAG 2.2 and Section 508 requirements. The PAC PDF Accessibility Checker has been used globally since 2010, demonstrating that PDF testing has been an established discipline for well over a decade. PDF Audit's standards overview describes the need to combine automated validation with manual checks such as contrast, tag structure, title and H1 matching, tab order, and bookmarks.

Practical rule: Treat an automated pass as permission to begin human testing, not as evidence that testing is finished.

The rest of the process depends on this separation. Run the scan, interpret its findings, inspect the structure, use the document with a keyboard, and listen to it with a screen reader. That workflow is more demanding than a score-only process, but it reflects how people experience PDFs.

Running Automated Accessibility Scans

Start with an automated scan because it creates a consistent inventory of detectable issues. It also gives remediation teams a useful first view of whether a document has basic structural foundations.

Use Adobe Acrobat Pro for an initial diagnostic

In Adobe Acrobat Pro:

1. Open the PDF.
2. Select the accessibility checking workflow.
3. Run Check for accessibility.
4. Choose the relevant checking options and standards available in your environment.
5. Review the results panel.
6. Open each reported issue and fix failures individually.
7. Re-run the check after changes.

Adobe's documented workflow is deliberately iterative. The checker identifies issues, but the author or remediator still has to decide how each issue should be corrected. Adobe's accessibility verification guidance also emphasizes reviewing tags, alternative text, reading order, tables, forms, and contrast rather than treating the report as a complete usability verdict.

PAC 2026 provides another useful validation layer. It checks documents against ISO 14289, PDF/UA, and WCAG 2.2 Level AA, making PDF/UA and WCAG 2.2 practical standards anchors for a checking process. The PAC 2026 quickstart guide explains its role as a standards-oriented PDF checker.

For large repositories, use batch-oriented validation where possible. A command-line tool such as veraPDF can help teams scan many files consistently, produce machine-readable results, and identify recurring defects across folders or publishing systems. Batch output is particularly useful for inventory and triage, but it still won't replace review of meaning or assistive technology behavior.

What Automated Tools Catch	What Requires Manual Verification
Missing or incomplete tag structures	Whether tags represent the intended semantics
Missing document language properties	Whether language changes within sections are identified correctly
Untagged annotations and some interactive objects	Whether links and controls make sense in context
Some missing form labels and field properties	Whether labels are understandable and announced correctly
Structural heading problems	Whether the visual and semantic hierarchy actually matches
Detectable PDF/UA or WCAG rule failures	Whether a screen reader presents content in a logical sequence

Use a standards-aware PDF accessibility checker guide to compare tool output with the checks your team needs to perform manually. The important distinction is simple: automation establishes a baseline floor. It doesn't establish a compliance ceiling.

Manual Checks That Automated Tools Cannot Perform

Manual inspection begins where the results panel ends. The reviewer needs to open the document's structure and ask whether each object means what it claims to mean.

Inspect the tag tree for semantics

Expand the tag tree and compare it with the visible document. A main heading should use an appropriate heading tag, subordinate headings should follow a coherent hierarchy, paragraphs should use paragraph tags, and lists should use list structures such as L and LI. Generic containers may be technically present but semantically unhelpful.

Pass: the structure reflects the document's meaning, heading levels are coherent, and lists are announced as lists.

Fail: headings are represented as ordinary paragraphs, list items are separate text fragments, or the tag tree contains meaningless nesting that changes how content is presented.

Reading order needs its own review. Use Acrobat's Order panel, then inspect the document in a reflowed or text-selection view. Content should move from one logical item to the next, especially in multi-column reports, brochures, and forms. Decorative lines, background shapes, and visual flourishes should be marked as artifacts rather than inserted into the reading sequence.

Pass: a user can follow the content without guessing what comes next.

Fail: columns are read across the wrong direction, captions appear before unrelated content, or decorative objects interrupt the document.

Review images, tables, and forms

Alternative text must describe the image's purpose in context. A chart needs a useful summary of its relevant message, while a decorative image needs an empty alternative rather than a meaningless description.

Pass: informative images have concise, accurate descriptions, and decorative images are ignored by assistive technology.

Fail: the alternative text repeats a filename, describes irrelevant visual detail, or omits information the surrounding text doesn't provide.

Tables require more than visible gridlines. Header cells should use TH tags with appropriate scope, while complex tables may need correct ID and HEADERS associations. Test whether a screen reader can identify the relevant row and column headers while moving through data.

For forms, every input needs a programmatic label, a sensible field name, and a useful tooltip where appropriate. A form fails when a user can reach a field but can't determine what information belongs there.

Check document properties for the primary language and any meaningful language changes within the content. Measure text and background combinations with a tool such as Colour Contrast Analyser. For scanned documents, verify OCR quality by searching, selecting, and listening to text. Confirm that fonts are embedded and that security settings don't prevent assistive technology access.

Pass: users can select, search, browse, and interpret the content.

Fail: text is only an image, characters are misrecognized, fonts substitute unpredictably, or permissions block accessibility features.

For teams comparing manual quality assurance with automated workflows, Refact's resource on automation testing for your app offers useful context on where automation helps and where human judgment remains necessary. When remediation involves public-sector deliverables, document the evidence needed to produce Section 508 compliant documents, including both machine results and manual observations.

Testing With Screen Readers and Keyboard Navigation

A screen reader test answers the question that a rule checker can't: can a person use this document without reconstructing its intended meaning? Test with more than one assistive technology when the document is important or complex. Common combinations include JAWS with Chrome, NVDA with Firefox or Chrome, and VoiceOver with Safari, although the exact environment should reflect your users and support commitments.

Start with headings. Move through them using the screen reader's heading navigation command and check whether the hierarchy matches the visible document. Listen for skipped levels, repeated headings, unlabeled sections, and headings announced as ordinary text.

Then test the content types most likely to expose structural defects:

• Lists: Confirm that the screen reader announces the list, its item count when supported, and each item in the right sequence.
• Tables: Move across rows and columns and listen for the correct headers. A table that sounds like disconnected numbers has failed, even if its tags appear complete.
• Images: Confirm that informative images receive meaningful descriptions and decorative images remain silent.
• Forms: Move through every field and verify that each label, instruction, required state, and error message is announced.
• Links: Check that link names communicate destinations or actions without forcing users to hear raw addresses.

Watch for announcements such as “blank,” skipped content, duplicated text, isolated punctuation, or mispronounced acronyms. These clues often reveal an incorrect reading order, an artifact that wasn't marked correctly, or a broken text layer.

Keyboard testing exposes a different class of problem. Start at the beginning and use only the keyboard:

1. Move through links, fields, buttons, and other controls with Tab.
2. Check that focus follows a sensible order.
3. Confirm that every interactive element receives visible focus.
4. Use the expected keyboard command to open, select, submit, or close each control.
5. Verify that no element traps focus.
6. Return through the sequence with reverse navigation where supported.

A fillable form should be tested from start to finish, not just field by field. A financial report needs checks for multi-column order, footnotes, repeated headers, and charts. A long policy document needs heading navigation, bookmarks, page movement, and find-in-document behavior.

A passing PAC report and a failing screen-reader session aren't contradictory. They measure different layers. Use this guide to NVDA VoiceOver JAWS testing when you need a repeatable assistive technology test plan and a consistent way to record failures, affected pages, user impact, and reproduction steps.

Prioritizing Remediation Across Large Document Libraries

A large PDF library needs triage before it needs perfection. In scholarly PDF research, 74.9% of documents failed to meet any tested accessibility criteria, while only 3.2% satisfied all tested criteria. The research study supports a staged audit model: inventory the library, classify failure types, assess severity, and fix recurring structural problems before polishing isolated files.

Rank documents using four questions:

• Who needs the document? Public guidance, student materials, benefits information, and customer forms usually reach broader audiences than internal reference files.
• What happens if access fails? A blocked application, inaccessible procurement form, or unusable policy can create more serious consequences than a low-traffic brochure.
• Can the source be repaired? A tagged source document may be easier to remediate than a scanned image-only file or a design-heavy publication.
• Should the PDF exist at all? A frequently updated policy, service page, or instruction set may work better as accessible HTML, with the PDF retained only when a fixed downloadable format is necessary.

Priority Level	Document Criteria	Legal Risk	Recommended Action
Critical	Public forms, essential services, high-use documents, or legally sensitive content	High	Remediate immediately, provide an accessible alternative, and retest with assistive technology
High	Public guidance, education resources, customer policies, or frequently downloaded files	Material	Schedule a full two-layer audit and repair recurring structural defects
Medium	Internal documents with a defined audience and ongoing operational use	Context-dependent	Apply automated screening, manual sampling, and planned remediation
Low	Superseded, archival, rarely accessed, or near-retirement files	Lower while unavailable to active users	Archive, replace, or retire after confirming retention obligations

This framework prevents teams from spending all their time on visual refinements while essential forms remain unusable. It also helps legal, content, and engineering teams agree on why one document moves ahead of another.

Track each file with its owner, source format, audience, publication location, last review, automated findings, manual findings, screen-reader status, remediation decision, and next review date. When the same defect appears across many files, fix the template or export process rather than correcting each PDF independently.

Producing an Accessibility Audit Report for Governance

An audit report should help people make decisions, not merely preserve a list of technical errors. Give every finding an identifier, affected page or object, relevant standard, severity, user impact, recommended correction, owner, and verification status.

Build the report around evidence

Start with scope. Record the files reviewed, versions, tools, standards, operating systems, browsers, screen readers, and test dates. Identify which checks were automated and which were manual. That distinction protects the report from implying that a machine-only result proves usability.

Use PDF/UA and WCAG 2.2 as the technical reference points, and map findings to the applicable Section 508 or organizational requirements. Avoid presenting a single score without explaining its calculation. If your team reports a conformance percentage, define the denominator, distinguish applicable from non-applicable criteria, and preserve the underlying pass, fail, and not-tested records.

A useful report separates:

• Structural findings, such as missing tags or language properties.
• Meaning findings, such as inaccurate alternative text or misleading heading semantics.
• Interaction findings, including keyboard order, form labels, and focus behavior.
• Assistive technology findings, including announcements, skipped content, and table navigation.
• Governance findings, such as missing ownership, version history, or an absent remediation deadline.

Make executive summaries actionable

Executives need the affected population, business importance, risk category, remediation approach, resources required, and decision date. Legal teams need an audit trail that shows what was tested, what was found, what was fixed, and what remains open. Content owners need page-level instructions they can act on without translating specialist terminology.

Keep original reports, repaired versions, screenshots where useful, tool exports, screen-reader notes, and approval records under version control. Don't overwrite evidence when a document changes. A defensible governance record connects the published file to its review, remediation, validation, and release decision.

For teams that need a formal conformance artifact, the accessibility conformance report guide can help you reduce legal risk with an ACR by organizing claims, supporting evidence, and known limitations in a consistent format.

Governance standard: A report is complete only when another qualified reviewer can understand what was tested and reproduce the material findings.

Building a Repeatable PDF Accessibility Workflow

A sustainable process begins before the PDF is exported. Require every new document to have an identified owner, a source file that uses semantic styles, a document title and language, an accessibility purpose for every image, and a decision about whether PDF is the right format.

Use a role-based workflow:

1. Content authors create meaningful headings, lists, tables, links, and alternative text in the source document.
2. Accessibility specialists run automated checks, inspect the tag tree, verify reading order, and test representative documents with assistive technology.
3. QA leads confirm that defects are resolved, evidence is stored, and the approved version matches the published file.
4. Governance owners monitor the backlog, assign deadlines, and escalate critical failures.

A practical review cycle gives high-traffic and legally sensitive documents a full two-layer audit on a recurring schedule. Archival content can receive automated scanning with documented spot checks, provided the organization confirms that the material remains appropriate to retain and publish.

Integrate checkpoints into the CMS or content calendar. The publishing gate should reject files with missing structural foundations, while the remediation queue should distinguish urgent user-impact failures from lower-risk improvements. For documents containing links, LinkShip's PDF linking guide is a useful resource for reviewing link creation and document navigation as part of the broader publishing workflow.

Keep one central record for document status, findings, owners, remediation decisions, validation evidence, and review dates. WebAbility.io offers a PDF Accessibility Checker that lets teams upload a PDF or provide a URL, receive an accessibility score, review issues mapped to WCAG and PDF/UA, and see an estimated remediation time. Use that kind of automated service as one component in the wider process, alongside manual inspection and screen-reader validation.

A PDF accessibility check works best when it becomes part of content governance rather than a final emergency before publication. Scan early, inspect meaning, test realistic tasks, prioritize users who depend on access, and preserve evidence of every decision.

---

If your team needs a practical way to assess PDF structure, prioritize remediation, and connect document testing with broader accessibility governance, visit WebAbility.io to explore its PDF checking, monitoring, reporting, and accessibility management tools. Start with your highest-impact documents, run the two-layer review, and turn the results into an owned remediation plan.