Playbook

Accessibility Checklist

A practical WCAG 2.1 AA compliance guide for government and nonprofit websites. Use this as a reference for audits, a training tool for your team, and a framework for building accessibility into your process.

Critical = blocks users entirely Standard = important for compliance

What's Inside

Why Accessibility Matters

The Legal Reality

Government websites are subject to Section 508 of the Rehabilitation Act, which requires federal agencies — and any organization receiving federal funding — to make electronic information accessible to people with disabilities. State and local governments are covered under Title II of the ADA. The DOJ has made it increasingly clear that websites are "places of public accommodation."

In April 2024, the DOJ published a final rule establishing WCAG 2.1 AA as the technical standard for state and local government web content. Compliance deadlines range from April 2026 to April 2027 depending on population size. This isn't theoretical anymore — it's a mandate with a deadline.

The Ethical Case

One in four American adults lives with a disability. When your website doesn't work with a screen reader, when your forms can't be completed with a keyboard, when your PDFs are just scanned images — you're excluding the people who often need your services most.

The Business Case

Accessible websites are better websites for everyone. Captions help people watching without sound. Good color contrast helps people on mobile devices in bright sunlight. Keyboard navigation helps power users. Clear form labels reduce errors for everyone. Investing in accessibility improves the experience for 100% of your users, not just those with disabilities.

The WCAG 2.1 AA Checklist

WCAG 2.1 is organized around four principles: content must be Perceivable, Operable, Understandable, and Robust (POUR). Below is a practical checklist for each principle.

Perceivable

Users must be able to perceive the content. It can't be invisible to all their senses.

All images have meaningful alt text (or empty alt for decorative images) Critical
Video content has captions and audio descriptions Critical
Audio content has transcripts available Critical
Color is not the only means of conveying information Critical
Text has a contrast ratio of at least 4.5:1 against its background Critical
Large text (18px bold or 24px) has a contrast ratio of at least 3:1
Text can be resized up to 200% without loss of content or functionality Critical
Content does not require horizontal scrolling at 320px width
UI components and graphics have a contrast ratio of at least 3:1
Spacing between text (line height, paragraph, letter, word) can be adjusted without breaking layout

Operable

Users must be able to operate the interface. It can't require interactions they cannot perform.

All functionality is available via keyboard alone Critical
No keyboard traps — users can navigate to and away from all elements Critical
Skip navigation link is present and functional Critical
Page titles are descriptive and unique Critical
Focus order follows a logical sequence Critical
Link purpose is clear from text (no 'click here' or 'read more')
Multiple ways to find content (nav, search, sitemap)
Headings and labels describe their content Critical
Focus is visible on all interactive elements Critical
No content flashes more than 3 times per second Critical
Motion can be disabled (prefers-reduced-motion respected)
Timeouts are warned about and can be extended

Understandable

Users must be able to understand the content and how to use the interface.

Page language is declared in the HTML lang attribute Critical
Language changes within content are marked up
Navigation is consistent across pages Critical
Components that share functionality are identified consistently
Form inputs have visible labels Critical
Error messages identify the field and describe the error clearly Critical
Error prevention: users can review, correct, and confirm before submitting
Instructions don't rely solely on sensory characteristics ('the red button', 'the field on the left')

Robust

Content must be robust enough to work with current and future assistive technologies.

HTML validates without significant errors
ARIA attributes are used correctly (valid roles, states, properties) Critical
Custom components communicate name, role, and value to assistive technology Critical
Status messages are communicated to screen readers via ARIA live regions
Content works across current browsers and assistive technologies Critical

Testing Your Site

Automated tools catch roughly 30-40% of accessibility issues. The rest require manual testing and real user feedback. A thorough testing approach uses all three methods.

Automated Testing Tools

axe DevTools

Browser Extension

The industry standard for automated accessibility testing. Catches ~30-40% of WCAG issues with zero false positives.

WAVE

Browser Extension

Visual overlay that shows accessibility issues in context. Great for content authors and non-developers.

Google Lighthouse

Built into Chrome

Automated auditing tool that includes accessibility scoring. Good for quick checks and CI/CD integration.

Pa11y

Command Line

Automated accessibility testing that runs from the command line. Perfect for CI/CD pipelines and bulk testing.

Manual Testing Essentials

Every accessibility audit should include these manual tests:

  • Keyboard navigation test — Put your mouse in a drawer. Tab through your entire site. Can you reach everything? Can you see where focus is? Can you escape every modal and dropdown?
  • Screen reader testing — Use NVDA (free, Windows), VoiceOver (built into macOS/iOS), or TalkBack (Android). Navigate your key user journeys. Does the content make sense in the order it's read? Are interactive elements announced correctly?
  • Zoom testing — Set browser zoom to 200%. Does everything still work? Is any content cut off or overlapping?
  • Color and contrast — View your site in grayscale. Can you still understand all information? Use a contrast checker on every text/background combination.

User Testing

The most valuable accessibility testing involves real users with disabilities. Recruit participants who use assistive technology daily. Watch them complete your top tasks. The insights from one hour of user testing are worth more than a hundred automated scans.

Common Violations We See

After auditing dozens of government and nonprofit websites, these are the issues we find most frequently. If you only have time to check six things, check these.

Critical

Missing Alt Text

Images without alternative text are invisible to screen reader users. Every meaningful image needs a description; decorative images need empty alt attributes.

How to fix: Audit all images. Add descriptive alt text or aria-label. Use alt="" for purely decorative images.

Critical

Poor Color Contrast

Text that doesn't meet contrast requirements is hard to read for users with low vision — and for everyone on a sunny day.

How to fix: Use a contrast checker. Ensure 4.5:1 for normal text, 3:1 for large text. Fix brand colors if they don't meet standards.

Critical

No Keyboard Navigation

Custom components (dropdowns, modals, tabs) that only work with a mouse lock out keyboard and switch users entirely.

How to fix: Test every interactive element with Tab, Enter, Escape, and arrow keys. Add proper ARIA roles and keyboard handlers.

High

Inaccessible Forms

Form fields without labels, missing error messages, and unclear instructions make forms unusable for assistive technology users.

How to fix: Associate every input with a visible label via for/id. Provide clear error messages that identify the field. Use fieldset/legend for groups.

High

Missing Skip Links

Without a skip navigation link, keyboard users must tab through every navigation item on every page to reach main content.

How to fix: Add a 'Skip to main content' link as the first focusable element. Make it visible on focus.

High

Inaccessible PDFs

Government sites are full of PDFs — and most of them are scanned images with no text layer, no heading structure, and no reading order.

How to fix: Remediate existing PDFs with proper tags, reading order, and alt text. For new content, publish as HTML first, PDF second.

Remediation Priorities

You can't fix everything at once. Prioritize based on user impact. This framework helps you triage issues and create a realistic remediation timeline.

Critical

Fix immediately. These block users entirely.

  • — Missing alt text on functional images
  • — Keyboard traps
  • — No visible focus indicators
  • — Form inputs without labels
  • — Auto-playing media without controls

High

Fix within 30 days. These severely impact usability.

  • — Insufficient color contrast
  • — Missing skip navigation
  • — Inaccessible custom components
  • — Missing page titles
  • — Inaccessible PDF documents

Medium

Fix within 90 days. These cause friction.

  • — Missing language declarations
  • — Vague link text ('click here')
  • — Inconsistent navigation patterns
  • — Missing ARIA landmarks
  • — Non-descriptive headings

Low

Plan for next redesign. These improve the experience.

  • — Enhanced touch target sizes
  • — Improved content readability
  • — Additional ARIA live regions
  • — Reduced motion preferences
  • — Enhanced focus management in SPAs

Maintaining Compliance

Accessibility isn't a project — it's a practice. Passing an audit once doesn't mean you'll pass the next one. Every new piece of content, every code change, every third-party widget is an opportunity to introduce new barriers. Here's how to stay compliant.

Train Your Content Authors

Most accessibility regressions come from content, not code. Train everyone who publishes content on: writing meaningful alt text, using proper heading hierarchy, creating accessible link text, formatting tables correctly, and publishing accessible documents. Make it part of onboarding.

Establish Development Standards

  • Accessibility requirements in every user story and acceptance criteria
  • Automated accessibility tests in your CI/CD pipeline (axe-core, Pa11y)
  • Manual accessibility testing as part of code review
  • Component library with accessibility built in — don't make developers solve the same problems repeatedly
  • Screen reader testing for any new interactive component

Regular Audits

Schedule comprehensive audits at least annually, with automated scans running continuously. Track your accessibility score over time. When it drops, investigate immediately — don't wait for the annual audit to discover six months of regressions.

Feedback Mechanism

Provide a clear, accessible way for users to report accessibility problems. Respond within 48 hours. Some of your best accessibility testers are the people using your site daily with assistive technology.

Need an accessibility audit?

We conduct thorough accessibility audits for government and nonprofit websites — combining automated testing, manual review, and expert analysis.

Get an Accessibility Audit