Checklist before delivering an accessible PDF

• Identify the final file by name, version and SHA-256.
• State the target standard, version, level and applicable legal context.
• List content types and important user tasks.
• Name the reviewer and the person making the delivery decision.

Survey the file and make a simple content map. Does it contain only headings and prose, or also charts, notes, tables, appendices and interactive fields? Identify recurring page types and unusual cases. This lets you choose checks matching the actual document.

Distinguish sampling from complete review. Three pages can reveal systematic defects and support planning; they cannot establish that another hundred pages are correct. If sampling is used, state its basis, coverage and limitations.

A difficult page and a typical page make useful starting points. A recurring template problem may warrant repair before further review. But a difficult table must not divert all attention from simple, consequential errors such as an incorrect application deadline.

• Text is accurate; numbers, characters and words have not disappeared.
• Headings, lists and reading order reflect the content.
• Table cells can be understood with the correct headers and units.
• Important images have useful text alternatives.
• Decoration does not disrupt reading and important information is not hidden.
• Language, title, links and any forms work.
• Contrast, use of colour and magnified reading have been assessed where applicable.

Retain validation reports, manual findings and practical test tasks. For each issue, record location, impact, proposed repair and whether it was retested. Distinguish checks not performed from requirements that do not apply.

A useful finding identifies location, requirement or expectation, observation and impact. For example: “Page 7, expenditure chart: the alternative says only Chart. Readers therefore miss the main comparison shown visually. Develop the description from the underlying data and confirm it with the owner.”

Then record responsibility and status. “Repaired” means someone made an edit; “retested” means the edit was checked. Keep these separate, particularly when several people work on the file. An unexplained check mark makes completion difficult to establish.

Assess impact in relation to the task. An incorrect heading level can hinder navigation; an inaccessible field can block an entire application. Priorities help organise repairs but do not change applicable requirements. Record lesser defects that still require attention.

If the file is optimised, signed, merged or exported again after review, assess which checks need repeating. The report must follow the final file, not an earlier working copy.

Make handover traceable with a dated assessment, final-file hash and clear outstanding issues. The publication decision-maker should understand coverage without reading every technical log, while the logs remain available for detailed investigation.

A checklist is a working aid. Its value comes from actual checks on the current document. Reuse the form across assignments, but never reuse one document’s approval as the answer for another.