This PDF accessibility checklist helps you review business documents and forms before sharing, publishing, submitting, or sending them for signature. It covers structure, reading order, tags, alternative text, contrast, form controls, keyboard access, language settings, and practical testing so accessibility is treated as part of document quality—not a last-minute correction.
Overview
An accessible PDF should be usable by people with different visual, motor, hearing, and cognitive needs, including people who use screen readers, keyboard navigation, magnification, or other assistive technology. Accessibility begins in the source document, but exporting to PDF does not guarantee that the result will remain accessible.
Use this checklist for reports, proposals, invoices, client forms, contracts, applications, policy documents, and scanned records. A scanned page is usually an image rather than readable document text, so it may require optical character recognition (OCR), a manual review, or both. If you scan documents online, retain the original where appropriate and check the OCR output for missing words, incorrect characters, and confusing reading order.
Accessibility requirements can vary by jurisdiction, industry, contract, and intended audience. WCAG can provide a useful reference framework, while a procurement agreement or applicable law may specify additional requirements. Treat this checklist as a quality-control workflow, not as a substitute for legal advice or a formal accessibility assessment.
Checklist by scenario
For a text-based business document
- Use real text. Confirm that paragraphs, headings, lists, and table content can be selected and copied. Do not rely on a page image when accessible text is available.
- Apply a logical heading structure. Use one clear document title, then organize sections with heading levels in a meaningful sequence. Do not choose heading styles only because they look larger or bolder.
- Set the document language. Add the primary language in the document properties and identify meaningful passages in another language when the tool supports it.
- Check reading order. A screen reader should encounter the title, headings, paragraphs, lists, tables, and captions in the intended sequence—not jump between columns, sidebars, or decorative elements.
- Tag the PDF. Confirm that the exported file contains a useful tag tree. Tags should identify headings, paragraphs, lists, tables, figures, and other meaningful content.
- Describe meaningful images. Add concise alternative text that communicates the purpose or information in a chart, diagram, photograph, or logo. Mark purely decorative images as decorative when the software supports that distinction.
- Review contrast and visual cues. Text should remain readable against its background. Do not communicate status, errors, or instructions with color alone; include words, symbols, patterns, or other supporting cues.
For an accessible PDF form
- Give every field a clear label. A field named “Date of birth” is more useful than one identified only by its position on the page. Labels should match the visible prompt and explain the expected format when needed.
- Use appropriate field types. Distinguish text fields, checkboxes, radio buttons, dropdowns, signature fields, and buttons. A field that looks like a checkbox but behaves like a text box creates avoidable confusion.
- Set a sensible tab order. Keyboard users should move through fields from top to bottom and left to right, following the form’s instructions and decision path.
- Identify required fields. Mark required fields programmatically and explain what happens when a user leaves one blank.
- Make error messages useful. State which field needs attention and how to correct it. Avoid relying on color or a vague alert such as “Invalid input.”
- Test signing and submission. If the form will be filled, signed online, or sent through an electronic signature workflow, verify that field labels, signature areas, consent language, and confirmation steps remain understandable and usable.
For a scanned document or converted PDF
- Run OCR and inspect every page, especially small print, stamps, handwriting, tables, checkboxes, and multi-column layouts.
- Confirm that the text layer follows the visible page and does not contain duplicated, missing, or nonsensical text.
- Add bookmarks for long documents and meaningful alternative text for diagrams or photographs that carry information.
- Preserve document security settings that allow assistive technology to access content. If restrictions are applied, test the final file rather than assuming the settings are harmless.
- Keep the scan legible at normal zoom and make sure important signatures, seals, and annotations are not cropped or hidden.
For a document sent to clients or the public
- Use a descriptive filename and document title. A consistent naming system also makes accessible files easier to identify and retrieve; see the PDF file naming conventions guide.
- Offer an accessible source or alternative format when a PDF cannot reasonably communicate the content.
- Explain how users can request help or report an accessibility problem, where appropriate.
- Check that links have descriptive text, work without a mouse, and do not expose long, unexplained URLs to screen-reader users.
What to double-check
Run a two-part review: an automated check followed by human testing. Automated tools can identify missing tags, suspicious reading order, absent form labels, contrast concerns, and other detectable issues. They cannot reliably judge whether alternative text is meaningful, whether headings accurately describe content, or whether instructions make sense.
Use keyboard-only testing first. Starting at the beginning of the file, press Tab and confirm that focus is visible, moves predictably, and reaches every interactive control. Check that you can open links, complete fields, select options, correct errors, and reach the signature or submission step without a mouse. Then test with a screen reader or arrange a review by someone familiar with assistive technology.
Check these details before approval:
- The file opens without warnings and has a meaningful title and language setting.
- Headings, lists, tables, links, and images have appropriate semantic roles.
- Tables have clear header relationships and are not being used only for page layout.
- Form labels, instructions, required states, and error messages are available to assistive technology.
- Focus order, keyboard access, zoom, contrast, and reflow work on the final exported file.
- Redacted or confidential information is actually removed, rather than merely covered by a shape or highlight.
Record the file version, reviewer, date, tools used, known limitations, and corrective actions. This creates a practical audit trail for internal review and makes the next update easier. Accessibility should be checked on the final version, after any conversion, compression, form-field addition, or electronic signing step.
Common mistakes
| Common failure | Why it matters | Practical fix |
|---|---|---|
| A scanned PDF has no text layer | Screen readers and search cannot interpret the page reliably. | Use OCR, proofread the result, and manually correct complex pages. |
| Visual text is bold but not tagged as a heading | Users cannot navigate the document structure efficiently. | Apply heading styles in the source and verify PDF tags after export. |
| Reading order follows columns incorrectly | Content may be heard in an unintelligible sequence. | Adjust the reading order and test with keyboard and screen-reader review. |
| Images use filenames as alternative text | The filename rarely communicates the image’s purpose. | Write concise, functional alternative text or mark decorative images accordingly. |
| Form fields have no meaningful names | Users cannot tell what information each control requests. | Match programmatic labels to visible prompts and expected input. |
| Color is the only error indicator | Some users may not perceive the distinction. | Add text, symbols, or an accessible error message. |
| The file is checked before signing or conversion | Workflow tools can change tags, fields, links, or permissions. | Repeat the accessibility review on the exact file that recipients receive. |
Another frequent mistake is treating accessibility as separate from document security and execution. A password restriction, flattened form, signature field, or conversion setting can change how a recipient interacts with the file. For related workflow guidance, review how to scan, fill, and sign a PDF online and confirm that the signing process does not remove usable labels or instructions.
When to revisit
Review this checklist before each new form launch, public release, procurement submission, client-facing template, or major document revision. Repeat testing after changing the source template, PDF editor, OCR or scanning process, electronic signature platform, security settings, branding, or form fields.
Schedule a broader compliance review during regular planning cycles and at least whenever applicable accessibility standards, contractual requirements, or legal guidance change. Tool updates can alter export behavior, tagging, reading order, or keyboard interaction, so do not assume a previously approved workflow will produce identical results forever.
For a practical final pass, assign one owner and use this sequence:
- Save a clearly named final draft and confirm the correct version.
- Run an automated accessibility check.
- Inspect tags, headings, reading order, alternative text, contrast, language, links, and tables.
- Complete the form with keyboard-only navigation and test any signing or submission controls.
- Review the file with a screen reader or qualified accessibility tester.
- Correct issues, retest the final export, and retain the review record.
Use the checklist again whenever the workflow changes. That habit is more reliable than assuming a PDF is accessible because it looks clean on screen.
