How to Check a PDF for Accessibility

To check a PDF for accessibility properly, use two kinds of review: an automated technical check and a manual check with human judgement. Start by confirming that the PDF has a usable tag structure, document title and language. Then run a PDF/UA audit for machine-testable structural rules. Finally, review reading order, alternative text, headings, tables, links and the real experience of using the document with assistive technology.

Start with the file itself. Use the free PDF accessibility checker for a local browser-based quick check. Your file is not uploaded unless you explicitly choose the full audit.

1. Check whether the PDF is tagged

Tags are the structural layer that tells assistive technology what the content means. A tagged PDF can identify headings, paragraphs, lists, tables, figures and other elements independently of where they appear visually on the page. Without that structure, a screen reader may receive little more than positioned text and graphics.

A quick accessibility check should therefore answer the basic question first: does the document contain a tag structure at all? If it does not, correcting smaller metadata problems will not solve the main accessibility barrier. Where the source file still exists, it is normally better to correct the source and export a tagged PDF again than to treat an untagged output as a finished document.

If a validator reports that the PDF claims to be tagged but has no usable structure, see Tagged PDF Errors Explained for the common failure patterns and the safest next step.

2. Check the document title and language

The document should contain a meaningful title and a declared language. These are small properties compared with the tag tree, but they affect how assistive technology introduces and pronounces the document. A missing title can cause software to announce an unhelpful filename; a missing language can lead to the wrong pronunciation rules.

These checks are useful early because they are objective and easy to repeat after an edit. They are also a reminder that accessibility is not only about what appears visually on the page: important information also lives in the PDF's internal structure and metadata.

3. Run a technical PDF/UA audit

PDF/UA (ISO 14289-1) defines accessibility requirements specifically for PDF. A PDF/UA validator can test many rules that are difficult to inspect reliably by eye, such as whether visible content is associated with the structure tree, whether roles and relationships are valid, whether annotations are tagged correctly and whether required metadata is present.

PDFChecks uses veraPDF for the optional full audit and translates machine-testable findings into plain-language issues. The full audit is deeper than the local quick check, so it uploads the file over an encrypted connection to the EU-hosted service. The interface makes that change explicit before any upload takes place.

Do not treat a passing automated result as a certification. A validator can establish that machine-testable rules passed; it cannot decide every question about meaning, usefulness or reading experience.

4. Review the reading order manually

Visual layout does not prove logical reading order. Multi-column pages, sidebars, callouts, headers, footers and positioned text can all create a sequence that looks correct to a sighted reader but is confusing when read linearly.

Review the document in the order exposed to assistive technology. Check that headings introduce the content that follows, lists stay together, captions remain with the relevant figures or tables, and repeated decorative content does not interrupt the main reading flow. This step requires human judgement because the correct order depends on meaning and context.

5. Check headings, lists and tables for meaning

A heading should be a real heading in the tag structure, not just large or bold text. Heading levels should describe the hierarchy of the document rather than the visual size chosen by the designer. Lists should expose list structure, not a series of paragraphs with typed bullet characters.

Tables need particular care. Header cells need to be identifiable and associated with the data they describe. A simple table can sometimes be checked quickly, but complex tables with multiple header levels or irregular layouts should be reviewed with assistive technology rather than judged from appearance alone.

6. Review images and alternative text

Automated tools can often detect that an image has no alternative text, but they cannot reliably decide whether the text is useful. The right description depends on why the image is present. A chart may need to communicate its trend or conclusion; a functional icon may need to communicate its action; a decorative image may need to be excluded from the reading experience rather than described.

Read the alternative text in context. Ask whether a person who cannot see the image receives the information needed to understand the surrounding content. Avoid descriptions that merely repeat nearby text or state that the object is an “image” without conveying its purpose.

7. Check links and interactive elements

Link text should make sense when encountered without the surrounding paragraph. Repeated “click here” links are harder to navigate than descriptive labels. If the PDF contains form fields, annotations or other interactive elements, verify that they are represented in the structure and can be reached and understood without relying on a mouse.

8. Understand PDF/UA and WCAG as related, not interchangeable

PDF/UA is the PDF-specific standard used for technical conformance checking. WCAG describes broader accessibility outcomes for digital content. They overlap in areas such as text alternatives, structure and meaningful navigation, but a PDF/UA validator does not replace a WCAG review and a generic WCAG checklist does not test the PDF file format in the same depth.

For the practical differences, read PDF/UA vs WCAG: which standard applies to PDFs?. The important point is to use automated validation for the rules software can prove and manual review for the questions that depend on meaning and user experience.

9. Fix the source document when possible, then retest

If the PDF came from Word, PowerPoint, InDesign or another authoring tool, durable fixes usually begin in that source. Use real heading styles, structured lists and tables, meaningful link text and appropriate image descriptions before exporting again with accessibility tags enabled. The guide How to Make a Word Document Export as an Accessible PDF covers the common Word workflow.

After making changes, repeat both the automated and manual checks. Retesting matters because one edit can alter structure elsewhere in the file. Keep the original source, the revised PDF and the results of the checks together if you need an audit trail.

A practical PDF accessibility checklist

The PDF has a usable tag structure.
The document has a meaningful title and declared language.
Automated PDF/UA findings have been reviewed and addressed where appropriate.
Reading order has been checked manually.
Heading hierarchy and list structure match the document's meaning.
Tables have understandable headers and relationships.
Images have appropriate alternative text or are correctly treated as decorative.
Links and interactive elements are understandable and keyboard-usable.
The final document has been reviewed with assistive technology where the context or risk warrants it.

Check the revised PDF. Run the PDF accessibility checker again after each substantive export or remediation step, then complete the manual checks that automated software cannot judge.

Reviewed 12 September 2026. Standards basis: PDF/UA-1 (ISO 14289-1). This guide explains a checking workflow; it is not legal advice and an automated pass is not a certification of accessibility or legal compliance.

Related guides

← Back to all guides