All resources
ChecklistBy Logan Nathan · Jul 2026 · 15 min read

Government Website ADA Compliance Launch Checklist: 47 Items Before You Go Live

47 specific, testable items across 7 categories. Run it before your next launch, or use it to audit the site you inherited. Items marked Critical are non-negotiable for WCAG 2.1 AA.

How to use this checklist: Walk your web team through each category before launch. Critical items should block go-live if they fail. Everything else matters, but you can carry it into a documented post-launch remediation plan without inviting a DOJ letter. Before your first review session, it helps to run a scan of the site and point an AI PDF audit tool at the document archive so you walk into the meeting with data on what will fail.

Checklist items by category

47 total across 7 categories

How the 47 pre-launch items distribute across the seven review areas.

C. Content and Publishing
9
A. Template and Design
8
D. PDF and Documents
8
B. Navigation and Structure
7
E. Forms and Digital Services
6
F. Legal and Documentation
5
G. Monitoring and Ongoing
4
Content and PDFs together account for 17 of the 47 items, more than a third of the pre-launch review.
A

Template and Design (8 items)

Color contrast: body text passes 4.5:1 against backgroundCritical

Use a contrast checker (WebAIM Contrast Checker, Colour Contrast Analyser) to verify every foreground/background text combination. Test body text, heading text, UI labels, and placeholder text. 4.5:1 is the WCAG minimum; target 7:1 for body text on government sites.

Large text contrast passes 3:1Critical

Text at 18px+ regular weight, or 14px+ bold weight, requires 3:1 contrast. Verify headings, lead paragraphs, and callout text at the threshold sizes.

Non-text UI elements pass 3:1 contrastCritical

Form borders, focus indicators, icon buttons, data chart elements, and other non-text UI components need 3:1 contrast. This is WCAG 1.4.11 (Non-text Contrast), added in WCAG 2.1.

Focus indicator visible at 3:1 contrast against adjacent colorsCritical

When a keyboard user focuses any interactive element (link, button, input, select), the focus indicator must be clearly visible. Test by tabbing through the page with no mouse. The focus ring must not be the browser default that has been suppressed by CSS outline: none.

Skip-to-content link is the first focusable elementCritical

A 'Skip to main content' link must appear when the page first receives keyboard focus. Test: open the page, press Tab once. The skip link should appear visually and announce correctly to a screen reader.

Text can be resized to 200% without loss of content or functionality

In browser settings, zoom to 200%. Verify all content is still visible, navigation is functional, and no content is clipped or scrolls horizontally unexpectedly.

No content flashes more than 3 times per second

Animated content that flashes rapidly can trigger seizures in users with photosensitive epilepsy. Check all animated elements (carousels, loading spinners, video) for flash rate. WCAG 2.3.1.

Decorative images have empty alt text (alt='')

Images that are purely decorative and convey no information should have alt='' (empty alt attribute, not absent). This causes screen readers to skip the image rather than announce file names.

B

Navigation and Structure (7 items)

All navigation and interactive features are fully keyboard operableCritical

Every link, button, form input, select, modal trigger, tab panel, and custom widget must be reachable and operable using only the keyboard. Use Tab to move forward, Shift+Tab to move backward, Enter/Space to activate. No mouse required.

Keyboard focus never becomes trappedCritical

Test dropdown menus, modal dialogs, date pickers, and all interactive components. Focus must be able to exit any component. If a modal opens, it should trap focus within the modal, but Escape should close the modal and return focus to the trigger element.

Page language is set in the HTML lang attributeCritical

The <html lang='en'> attribute must be correctly set. Screen readers use this to determine language voice and pronunciation rules. For multi-language sites, each page in each language must have the correct lang attribute.

Page has a descriptive, unique titleCritical

The <title> element should identify the page content and the organization: 'Pay Your Property Tax | City of Springfield', not 'Home' or 'Page.' Screen reader users often review the page title to confirm they've arrived at the right destination.

ARIA landmarks are used for page regionsCritical

Main content should be in a <main> element. Navigation in a <nav> with aria-label to distinguish multiple navs. Sidebar content in <aside>. Header and footer in semantic elements. Screen reader users move by landmarks; without them, the page structure is invisible.

Navigation menus tested with screen readers (NVDA + Chrome, VoiceOver + Safari)

Move through all menus using a screen reader. Verify dropdown expanded/collapsed state is announced correctly. Verify submenu items are reachable. Verify menu item count is announced if applicable.

Breadcrumbs present on interior pages with proper aria-label='breadcrumb'

Breadcrumbs help users understand their location within the site hierarchy. They must be marked up with aria-label='breadcrumb' and the current page should be marked with aria-current='page'.

C

Content and Publishing (9 items)

All meaningful images have descriptive alt textCritical

Alt text must describe the purpose of the image in context. 'City Council meeting' is inadequate. 'Mayor Johnson and four council members at October 2026 budget hearing' is adequate. Test by disabling images in browser and reading alt text aloud.

Heading hierarchy is logical and semantic (H1, H2, H3, no skips)Critical

Each page should have one H1 (the page title). Subheadings should be H2. Subsections of H2 sections should be H3. Never skip heading levels for visual effect. Use CSS for styling, not heading levels.

Link text is descriptive and unique (no 'click here', 'read more', 'learn more')Critical

Screen reader users often move through a page by reading a list of all links. 'Read more' is meaningless when listed. 'Read the FY2027 Budget Summary' is meaningful. Every link text should describe its destination clearly.

Color is not the only means of conveying informationCritical

Never use color alone to indicate required fields (red border only), error states (red text only), or informational status. Always pair color with text, iconography, or pattern.

Alt text policy is documented and communicated to all content editors

Compliance requires not just correct alt text today but a policy that keeps it correct as content is updated. Is there a written policy? Are all editors trained on it? Is it enforced by the CMS?

Accessible reading level targets are established for public-facing content

Content intended for general public should target 8th grade reading level (Flesch-Kincaid Grade 8 or lower). This is not a WCAG requirement but is a best practice for serving diverse literacy levels in government audiences.

Tables have proper header cells with scope attributes

Every data table must have <th> elements identifying column and/or row headers. The scope='col' or scope='row' attribute associates headers with data cells. Layout tables (used for positioning) should have role='presentation' or be converted to CSS layouts.

All pages have meaningful meta descriptions

While not a WCAG requirement, descriptive meta descriptions help search engine users and give content previews that let users with cognitive disabilities decide if a page is relevant before clicking.

Content is tested for cognitive accessibility (clear structure, plain language, predictable navigation)

WCAG 2.1 includes cognitive accessibility criteria that go beyond screen reader compatibility. Verify that navigation is predictable across pages, that instructions don't rely solely on shape/location/color, and that help is available for complex tasks.

D

PDF and Documents (8 items)

Full PDF archive has been audited and risk-classifiedCritical

Before launch, you need to know the accessibility status of every document on the site. A bulk PDF scan classifies each document by risk level. This audit should be complete before go-live, not scheduled for after.

All Critical-classified PDFs (image-only, no text layer) have been remediated or replacedCritical

Image-only PDFs are completely inaccessible to screen readers. There is no acceptable exception for publishing image-only PDFs unless an accessible alternative is provided. These must be OCR-processed, replaced, or removed before launch.

All High-risk PDFs related to active services have been remediatedCritical

PDFs that provide access to services residents currently need (applications, benefits information, notices, rate schedules) cannot benefit from the preexisting document exception. They must be remediated before launch.

All new PDF uploads are scanned at upload for accessibility complianceCritical

Platform-level PDF scanning at upload is the only mechanism that prevents new non-compliant documents from being published. Verify this is active and cannot be bypassed by content editors.

Accessible HTML alternatives are available for complex documents

For documents too complex to remediate as PDFs (multi-column layouts, complex infographics), a linked HTML alternative should be available on the same page as the PDF download.

PDF documents have descriptive titles set in metadata (not filename)

Open each PDF in Acrobat, go to File, Properties, Description, and verify the Title field contains a meaningful document title. Screen readers announce this title when the PDF is opened.

Form PDFs have been replaced with accessible web forms or tagged interactive PDFs

Fillable PDF forms are consistently the most problematic document type for screen reader users. Where possible, replace with accessible HTML forms. If PDF forms must remain, they require proper form field tagging in Acrobat.

An accessible document templates are available for staff to use for future documents

Staff need compliant Word, Excel, and PowerPoint templates that are pre-configured to export accessible PDFs. Without these templates, new violations will be created continuously as staff create new documents.

E

Forms and Digital Services (6 items)

All form fields have programmatically associated labelsCritical

Every input, select, and textarea must have a <label> element associated via for/id attributes. Placeholder text alone is not sufficient. It disappears when the user starts typing and isn't reliably announced by all assistive technology.

Error messages identify the specific field and describe how to fix the errorCritical

WCAG 3.3.1 requires that errors are identified in text (not just color). WCAG 3.3.3 (Level AA) requires that error suggestions be provided. 'Invalid input' fails both criteria. 'Please enter a valid 5-digit zip code' passes both.

Required fields are indicated with text (not color or asterisk alone)Critical

An asterisk (*) that requires visual color context to understand must be supplemented by a visible text legend ('* indicates required field') and ideally an aria-required='true' attribute on the input.

Form validation errors are announced to screen reader usersCritical

When form validation fires, the error announcement must reach screen reader users. Test with NVDA: submit a form with errors and verify the errors are announced without the user needing to move through the page to find them.

CAPTCHA has an accessible audio alternative or is replaced with accessible challenge method

Standard image CAPTCHA is inaccessible to users with visual impairments. If CAPTCHA is required, an audio alternative must be provided. Better options include honeypot fields, behavioral analysis, or Cloudflare Turnstile's accessibility-tested challenge.

Multi-step forms manage focus correctly between steps

When a multi-step form advances to the next step, focus should be programmatically moved to the heading or top of the new step content, not remain at the submit button or return to the top of the page.

F

Legal and Documentation (5 items)

Accessibility Statement is published and linked from every page footerCritical

The Accessibility Statement must include: conformance level claimed, date last updated, known non-conformances, contact information for the ADA coordinator, feedback mechanism, and grievance process. It should be reachable from any page in two clicks.

ADA Web Coordinator has been designated with contact information publishedCritical

Someone must be designated as the point of contact for digital accessibility issues. Their name, title, email, and phone number must be published on the Accessibility Statement and ideally on the Contact page.

VPAT (Voluntary Product Accessibility Template) is available for the CMS platform

If your agency is asked to provide accessibility documentation in a procurement review or complaint response, having your CMS vendor's current VPAT on file demonstrates that your platform is documented as accessible.

Feedback mechanism is functional (tested with a test submission)

Send a test submission through your accessibility feedback form or email address. Verify it arrives, is routed to the right person, and that a response process exists. A broken feedback mechanism compounds a compliance problem.

Staff training records are documented and stored

Training completion records are evidence of good-faith compliance efforts. Document who was trained, on what topics, on what date, and keep records for at least 3 years (or per your agency's records retention schedule).

G

Monitoring and Ongoing (4 items)

Weekly automated accessibility scan is scheduled and assigned to a reviewer

Automated scanning tools should be scheduled to run at minimum weekly on your highest-traffic pages. Results should go to a named person who reviews and assigns remediation tasks, not just sit in a report inbox.

Complaint and feedback response process is defined with SLA

Define: who receives accessibility complaints, how quickly they must respond (recommend 5 business days for initial acknowledgment, 30 days for resolution), and what the escalation path is if the issue cannot be resolved at first tier.

Annual third-party accessibility audit is scheduled and budgeted

A third-party WCAG 2.1 AA audit should be budgeted annually. The audit scope should include the main website, all high-traffic transactional portals, and a random sample of PDFs. Results should feed directly into the remediation backlog.

PDF upload scanner is active and cannot be bypassed

After launch, verify that the PDF scanning system is active, that non-compliant uploads are blocked (not just flagged), and that no content editor role has permission to bypass the scan and publish directly.

Critical items per category

24 of 47 are Critical

Items flagged Critical must pass before go-live. The rest carry into a documented remediation plan.

A. Template and Design
5/8
B. Navigation and Structure
5/7
C. Content and Publishing
4/9
D. PDF and Documents
4/8
E. Forms and Digital Services
4/6
F. Legal and Documentation
2/5
G. Monitoring and Ongoing
0/4
Template, Design, and Navigation carry 10 of the 24 Critical items. Monitoring has zero blockers, but every item still needs an owner.

Download the Printable Checklist

Grab the full 47-item checklist as a printable PDF. It's formatted for team review sessions with signature fields for sign-off by your IT director, communications director, and legal or compliance officer.

Get the Printable Version

Want a Platform That Handles Many of These Automatically?

WPPersona enforces items A1 to A5, B1 to B3, C1 to C4, D3 to D4, and E1 to E4 at the platform level. They can't fail without the platform alerting you first. See it in a live walkthrough.

Schedule a Free Demo