Implementation checklist

Document Accessibility Checklist

Use this source-backed checklist to publish accessible documents with consistent quality across HTML, Office, and PDF workflows.

Interactive checklist

Check items as you verify them. Progress is saved automatically in your current browser.

7 sections
1

Run a source-level authoring check before export.

2

Validate semantic structure and keyboard navigation.

3

Run automated scans plus manual assistive-technology checks.

4

Store evidence (results, owners, remediation actions) per release.

Overall progress: 0/28 complete (0%)

Loading saved checklist state...

Scope and baseline setup

Define ownership, standards, and publication scope before remediating files.

0/4 complete

How to verify: Your team playbook and acceptance criteria explicitly reference WCAG 2.2 A/AA.

How to verify: Each document type has an accountable owner and SLA target for fixes.

How to verify: Publishing policy includes format decision rules and exception handling.

How to verify: Policy notes ADA Title II timelines (April 24, 2026 or April 24, 2027, depending on population band).

Document structure and navigation

Users must navigate by title, headings, language, and meaningful landmarks.

0/4 complete

How to verify: Title and language metadata are present in the source and published output.

How to verify: Screen-reader heading list shows an ordered hierarchy without skipped levels.

How to verify: Keyboard/tab and screen-reader reading order are consistent across all pages.

How to verify: Links make sense when read out of context in a screen-reader links list.

Images, media, and visual contrast

Non-text content and visual styling must remain perceivable for assistive tech users.

0/4 complete

How to verify: Alt decisions are reviewed using the W3C decision tree for each image class.

How to verify: Warnings/status cues remain understandable in grayscale and with high-contrast modes.

How to verify: Body text reaches at least 4.5:1 (or 3:1 for large text) against backgrounds.

How to verify: Interactive controls, focus indicators, and chart markers reach at least 3:1 contrast.

Tables and data structures

Complex tables require explicit structure and navigable headers.

0/4 complete

How to verify: Table structure is announced as a table with rows/columns in assistive technology.

How to verify: Screen-reader cell navigation correctly announces related headers.

How to verify: Merged-cell usage is minimal and tested with keyboard + screen reader.

How to verify: Users can identify table purpose before entering cell-by-cell navigation.

Forms and interactive elements

Document forms must expose labels, instructions, errors, and keyboard operation.

0/4 complete

How to verify: Form fields announce labels and required state in screen readers.

How to verify: Submitting invalid data exposes error text that can be reached by keyboard and AT.

How to verify: No interaction requires a mouse; focus never gets trapped or lost.

How to verify: PDF form fields expose names/roles/values and follow logical tab sequence.

PDF-specific controls

When PDF is required, validate tags, reading order, and export quality in the final file.

0/4 complete

How to verify: Source templates enforce styles and semantic structure before PDF export.

How to verify: Tag tree reflects content order and role mapping without orphan/unmapped elements.

How to verify: Long documents include usable bookmark hierarchy matching headings.

How to verify: Automated findings are resolved and manual read-through confirms expected experience.

QA, monitoring, and evidence pack

Accessibility quality is a release process, not a one-time document cleanup.

0/4 complete

How to verify: Your CI/build outputs include automated accessibility results per document.

How to verify: Manual test notes are stored with pass/fail outcomes and issue IDs.

How to verify: Ticket states and due dates are visible for all accessibility defects.

How to verify: Evidence bundle can be generated for any published document set on demand.

Primary references used

This checklist is based on primary standards and government guidance. Review these sources directly when adapting controls for your organization.

Important: This page is operational guidance, not legal advice. For legal interpretations or jurisdiction-specific obligations, review with counsel.

FAQ

Can we pass this checklist with only automated scans?

No. DOJ guidance explicitly references both automated and manual testing. Automated scans catch many issues, but manual keyboard and assistive-technology testing is still required.

Should all documents stay in PDF?

No. Section508.gov guidance recommends creating pages in HTML where possible and using PDF only when format constraints require fixed layout output.

Is this checklist legal advice?

No. This is an operational implementation checklist based on primary standards and federal guidance sources. Teams should involve legal counsel for jurisdiction-specific interpretations.

How often should we run the checklist?

Run it during template onboarding, before major releases, and as part of quarterly accessibility governance reviews.

Next step

Run this checklist on one representative document set, log all failures by severity, then submit that sample to validate turnaround, QA workflow, and remediation evidence from end to end.

Related pages

Continue with connected guides and operational references.

6 linked pages