How to verify: Your team playbook and acceptance criteria explicitly reference WCAG 2.2 A/AA.
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.
Run a source-level authoring check before export.
Validate semantic structure and keyboard navigation.
Run automated scans plus manual assistive-technology checks.
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.
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.
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.
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.
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.
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.
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.
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.
W3C WCAG 2.2 Recommendation
Open official source
W3C WCAG 2.2 Quick Reference
Open official source
W3C Images Tutorial: Alt Decision Tree
Open official source
W3C PDF Techniques for WCAG
Open official source
Section508.gov: Create Accessible Documents
Open official source
Section508.gov: Create Accessible PDFs
Open official source
ADA.gov: 2024 Title II Web and Mobile Accessibility Rule
Open official source
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.
Resource hub
Central navigation for all operational and SEO guide clusters.
Open resource
Compliance guide hub
Legal and operational compliance content by topic.
Open resource
State requirement pages
State-by-state ADA Title II document requirement guides.
Open resource
Documentation hub
Technical remediation and workflow documentation.
Open resource
Request conversion
Submit a pilot set and validate this checklist in production.
Open resource
Contact team
Get implementation support for your document operation.
Open resource