# A practical PDF accessibility checklist.

Canonical page: https://districtproof.io/resources/pdf-accessibility-checklist

Use this checklist to start a document review. It covers common structure and usability issues, but it is not an exhaustive test or a conformance determination.

By [Nilesh Gadekar, Founder](https://districtproof.io/about#founder) · Last reviewed November 4, 2026.

0 of 15 review items checked. This checklist does not establish conformance.

Document title and primary language are set.Headings form a meaningful hierarchy using structural tags.Paragraphs, lists, and sections are tagged appropriately.Reading order follows the intended meaning.Meaningful images have useful alternative text.Complex charts have an appropriate text explanation.Tables identify headers and preserve row and column relationships.Links describe their destination or purpose.Scanned text has been recognized and checked for accuracy.Form fields have meaningful labels and a logical tab sequence.Instructions do not depend only on color, shape, or position.Text and meaningful visual information have sufficient contrast.Automated findings have been reviewed and resolved or recorded.Keyboard and screen-reader review covers the intended task.The file published online matches the reviewed version.

## Use the source file first

Apply heading styles, clear table structure, and meaningful image descriptions in the editable source. After exporting, review the actual PDF. Export settings and later edits can change the result.

## Record the scope of your review

Keep the filename, version, review date, methods, coverage, and unresolved findings. A check mark in this page is a personal planning aid and is not saved or sent to DistrictProof.

## Continue your review

See [WCAG 2.1](https://www.w3.org/TR/WCAG21/) and [W3C WAI tutorials](https://www.w3.org/WAI/tutorials/) for technical context. Explore [DistrictProof Docs](https://districtproof.io/solutions/docs) or the [deadline estimator](https://districtproof.io/resources/deadline-calculator).

## Use the checklist in three passes

First review the source and purpose. Identify the intended task, content owner, current version, and best available original. Check whether a web page or maintained template would be a better long-term format. That prevents effort being spent on an obsolete copy or on a file that should be replaced through a district-approved process.

Next review structure and content. Work through headings, reading order, images, tables, links, scans, and form behavior as applicable. A simple text notice and a combined packet will need different attention. Keep questions about meaning or unreadable originals separate from technical findings.

Finally review the delivered and published versions. The returned file should match the agreed scope and be accepted by the district’s content owner. After posting, verify that the public location serves that accepted version. A later export or replacement may need another check.

Illustrative district scenario

### A tagged menu still has confusing relationships

The document has tags, but a reader cannot tell which meal belongs to which day or whether a note applies to every item. The review needs to examine meaning and relationships rather than treating the presence of tags as a completed result. A better source layout may also make the next menu easier to produce.

## Record findings so someone can act on them

For each issue, identify the file and version, the location or relevant content, the observed problem, and the next action. Assign content questions to the district owner and technical corrections to the responsible production team. Keep the evidence specific enough that another person can understand what was reviewed.

A checklist is a planning aid. A project review should state the methods, technical criteria, scope, date, and remaining limits. Explore [DistrictProof’s quality model](https://districtproof.io/how-we-work/quality) for how automated checks, human review, and publication verification fit together.

## Technical references

The [W3C page-structure tutorial](https://www.w3.org/WAI/tutorials/page-structure/), [tables tutorial](https://www.w3.org/WAI/tutorials/tables/), and [forms tutorial](https://www.w3.org/WAI/tutorials/forms/) explain the underlying relationships and interactions in web content. For PDF work, the implementation must also be reviewed in the actual document format. Use [WCAG 2.1](https://www.w3.org/TR/WCAG21/) as the technical reference for an agreed WCAG review.