WCAG 2.1 AA Checklist for Government Websites: Every Requirement in Plain English

The DOJ's ADA Title II rule requires your government website to meet WCAG 2.1 Level AA. That means satisfying 50 specific "success criteria" — testable requirements organized under four principles.

If you're not sure where the ADA Title II deadline stands, read our breakdown first. But regardless of timeline, these requirements aren't going away — and the sooner you start, the stronger your compliance position.

This checklist translates every single criterion into plain English, tells you whether automated tools can detect it, and gives you the practical fix. Bookmark this page — it's your reference guide throughout the compliance process.

How to use this checklist

Each criterion is marked with one of these:

• Automated — Scanning tools like GovAccess can detect this automatically
• Manual — Requires human judgment to evaluate
• Partial — Automated tools catch some instances, but manual review is needed for full coverage

The criteria are organized by the four WCAG principles: Perceivable, Operable, Understandable, Robust.

Principle 1: Perceivable

Information and user interface components must be presented in ways that all users can perceive.

1.1 Text Alternatives

1.1.1 Non-text Content (Level A) — Automated

Every image, icon, chart, and graphic that conveys meaning needs a text alternative (alt text). Decorative images get empty alt text (alt="").

What to check: Do all <img> tags have an alt attribute? Is the alt text meaningful — does it convey the same information as the image?

Common government website issue: Staff photos with filename alt text ("IMG_4582.jpg"), seal/logo images with no description, meeting agenda header graphics with text baked into the image.

Fix: Add descriptive alt text to every meaningful image. For the city seal, use something like "City of Springfield Official Seal." For a photo of a council meeting, describe what's happening. For decorative borders and spacers, use alt="".

1.2 Time-Based Media

1.2.1 Audio-only and Video-only (Level A) — Manual

Pre-recorded audio needs a transcript. Pre-recorded video (no audio) needs either a transcript or an audio description.

Common issue: City council meeting audio recordings without transcripts.

1.2.2 Captions (Pre-recorded) (Level A) — Partial

All pre-recorded videos with audio must have synchronized captions.

Common issue: YouTube videos of public meetings embedded without captions enabled. YouTube's auto-captions are a start but often need editing for accuracy, especially with proper nouns (city names, staff names, ordinance numbers).

1.2.3 Audio Description or Media Alternative (Level A) — Manual

Pre-recorded video needs either audio description (narration of visual content during pauses) or a text transcript that describes both the audio and visual content.

1.2.4 Captions (Live) (Level AA) — Manual

Live video streams with audio (like live city council meetings) need real-time captions. Many municipalities use CART (Communication Access Realtime Translation) services or live captioning platforms.

1.2.5 Audio Description (Pre-recorded) (Level AA) — Manual

Pre-recorded video needs audio description when the visual content conveys information not available in the audio track alone. For talking-head videos, this usually isn't needed. For videos showing charts, demonstrations, or on-screen text, it is.

1.3 Adaptable

1.3.1 Info and Relationships (Level A) — Partial

Information conveyed through visual formatting must also be conveyed programmatically. Headings must use heading tags (h1–h6). Lists must use list elements. Tables must have proper header cells. Form fields must have associated labels.

What to check: Are headings actual <h1> through <h6> tags (not just bold text)? Do data tables have <th> header cells? Are list items in <ul> or <ol> elements?

1.3.2 Meaningful Sequence (Level A) — Manual

The reading order of content must make sense when CSS is disabled. Screen readers follow the DOM order, not the visual layout.

What to check: Disable CSS in your browser and read the page top to bottom. Does the content still make sense in that order?

1.3.3 Sensory Characteristics (Level A) — Manual

Instructions can't rely solely on shape, color, size, visual location, or sound. "Click the green button" fails if color is the only identifier. "Click the Submit button below the form" is better.

1.3.4 Orientation (Level AA) — Automated

Content must work in both portrait and landscape orientation unless a specific orientation is essential (like a piano app).

1.3.5 Identify Input Purpose (Level AA) — Partial

Form fields for common personal data (name, email, phone, address) should use the autocomplete attribute with appropriate values. This helps browsers auto-fill forms and helps assistive technology identify the field's purpose.

Fix: Add autocomplete="name", autocomplete="email", autocomplete="tel", etc. to your form inputs.

1.4 Distinguishable

1.4.1 Use of Color (Level A) — Manual

Color can't be the only way to convey information. A form that marks required fields with red text only — without an asterisk or the word "required" — fails this criterion.

Common issue: Error messages that only change the field border to red without any text explanation.

1.4.2 Audio Control (Level A) — Partial

If audio plays automatically for more than 3 seconds, users must be able to pause, stop, or control the volume independently of system volume.

1.4.3 Contrast (Minimum) (Level AA) — Automated

Text must have a contrast ratio of at least 4.5:1 against its background. Large text (18pt or 14pt bold) needs at least 3:1.

The most common failure on government websites. Light gray text on white backgrounds, white text on light blue headers, placeholder text in form fields — all frequent offenders.

1.4.4 Resize Text (Level AA) — Partial

Text must be resizable up to 200% without loss of content or functionality. No horizontal scrolling should be required.

What to check: Use your browser's zoom (Ctrl/Cmd +) to zoom to 200%. Does any content get cut off, overlap, or require horizontal scrolling?

1.4.5 Images of Text (Level AA) — Manual

Don't use images to display text when actual text could be used instead. Exceptions: logos and situations where a specific visual presentation is essential.

Common issue: Header banners with text baked into the image instead of using HTML text with CSS styling.

1.4.10 Reflow (Level AA) — Partial

Content must reflow at 320px width (for vertical scrolling) or 256px height (for horizontal scrolling) without horizontal scrolling or loss of information. This is essentially responsive design.

What to check: Set your browser window to 320px wide. Does all content still display without horizontal scrolling?

1.4.11 Non-text Contrast (Level AA) — Manual

UI components (buttons, form inputs, focus indicators) and meaningful graphics need at least a 3:1 contrast ratio against adjacent colors.

Common issue: Light gray form field borders that are hard to distinguish from the white background.

1.4.12 Text Spacing (Level AA) — Manual

Users must be able to adjust line height to at least 1.5x font size, paragraph spacing to 2x, letter spacing to 0.12x, and word spacing to 0.16x — without content being cut off.

What to check: Use a browser bookmarklet or extension to apply these text spacing values. Does any content overflow or get hidden?

1.4.13 Content on Hover or Focus (Level AA) — Manual

If additional content appears when hovering or focusing (like tooltips or dropdown menus), users must be able to dismiss it without moving focus, hover over the new content, and the content must persist until dismissed.

Principle 2: Operable

Users must be able to navigate and interact with the interface.

2.1 Keyboard Accessible

2.1.1 Keyboard (Level A) — Partial

All functionality must be available using only a keyboard. Every link, button, form field, and interactive element must be reachable and operable with Tab, Enter, Space, and arrow keys.

The second most critical requirement. Test every page by putting your mouse aside and navigating with only your keyboard.

2.1.2 No Keyboard Trap (Level A) — Partial

Users must be able to move focus away from any component using the keyboard. If a component requires non-standard keys to leave (like Escape for a modal), the user must be told.

Common issue: Embedded Google Maps that trap keyboard focus. Modal dialogs that can't be closed with Escape.

2.1.4 Character Key Shortcuts (Level A) — Manual

If keyboard shortcuts use single character keys (letters, numbers, punctuation), users must be able to turn them off, remap them, or they should only be active when the relevant component has focus.

2.2 Enough Time

2.2.1 Timing Adjustable (Level A) — Manual

If a time limit exists (like a session timeout on a payment form), users must be able to turn it off, adjust it, or extend it.

2.2.2 Pause, Stop, Hide (Level A) — Partial

Moving, blinking, scrolling, or auto-updating content that starts automatically and lasts more than 5 seconds must have a mechanism to pause, stop, or hide it.

Common issue: Auto-scrolling news tickers and image carousels without pause controls.

2.3 Seizures and Physical Reactions

2.3.1 Three Flashes or Below Threshold (Level A) — Partial

Nothing on the page should flash more than three times per second. This prevents seizures in people with photosensitive epilepsy.

2.4 Navigable

2.4.1 Bypass Blocks (Level A) — Automated

A mechanism must exist to skip repeated blocks of content (like navigation menus). Typically implemented as a "Skip to main content" link.

2.4.2 Page Titled (Level A) — Automated

Every page needs a descriptive <title> that describes its topic or purpose. "City of Springfield - Building Permits" is good. "Page" or "Untitled" is not.

2.4.3 Focus Order (Level A) — Manual

When navigating with the keyboard, the focus order must be logical and follow the visual reading order.

2.4.4 Link Purpose (In Context) (Level A) — Partial

The purpose of each link must be clear from the link text alone or from the link text plus its surrounding context. "Click here" with no context fails. "View the 2026 budget report" is clear.

2.4.5 Multiple Ways (Level AA) — Manual

There must be more than one way to find a page within your site — like a navigation menu plus a search function, or a site map plus breadcrumbs.

2.4.6 Headings and Labels (Level AA) — Partial

Headings and labels must describe their topic or purpose. "Section 3" is vague. "How to Apply for a Building Permit" is descriptive.

2.4.7 Focus Visible (Level AA) — Partial

The keyboard focus indicator must be visible. When you Tab through the page, you must be able to see which element is currently focused.

Common issue: CSS that removes the default focus outline (outline: none) without replacing it with an alternative focus style.

2.5 Input Modalities

2.5.1 Pointer Gestures (Level A) — Manual

If functionality requires multipoint or path-based gestures (like pinch-to-zoom on a map), a single-pointer alternative must exist.

2.5.2 Pointer Cancellation (Level A) — Manual

For actions triggered by a single pointer: either the down event doesn't trigger the action, the action can be aborted or undone, or the up event reverses the action.

2.5.3 Label in Name (Level A) — Automated

If a component has a visible text label, the accessible name must contain that visible text. A button that visually says "Search" must have an accessible name that includes "Search."

2.5.4 Motion Actuation (Level A) — Manual

If functionality uses device motion (like shaking), a user interface alternative must exist and motion actuation can be disabled.

Principle 3: Understandable

Content and interface operation must be understandable.

3.1 Readable

3.1.1 Language of Page (Level A) — Automated

The default language of the page must be programmatically determined. Add lang="en" to your <html> tag.

30-second fix that affects your entire site. One of the easiest criteria to satisfy.

3.1.2 Language of Parts (Level AA) — Manual

Any content in a different language than the page default must be identified. If your English page includes a paragraph in Spanish, wrap it in an element with lang="es".

3.2 Predictable

3.2.1 On Focus (Level A) — Manual

Moving keyboard focus to an element must not trigger an unexpected change of context (like navigating to a new page or opening a popup).

3.2.2 On Input (Level A) — Manual

Changing a form input must not automatically trigger an unexpected context change. A dropdown that auto-submits when you select an option violates this — add a separate "Go" button.

3.2.3 Consistent Navigation (Level AA) — Manual

Navigation menus that appear on multiple pages must be in the same relative order on each page.

3.2.4 Consistent Identification (Level AA) — Manual

Components with the same function must be identified consistently. If your search icon is labeled "Search" on the homepage, it shouldn't be labeled "Find" on subpages.

3.3 Input Assistance

3.3.1 Error Identification (Level A) — Partial

If a form input error is detected, the error must be identified and described in text. Don't just turn the field border red — tell the user what's wrong.

3.3.2 Labels or Instructions (Level A) — Partial

Forms must provide labels or instructions when user input is required. Every field needs a visible label explaining what to enter.

3.3.3 Error Suggestion (Level AA) — Manual

If an error is detected and suggestions for correction are known, provide them. "Please enter a valid email address (example: name@city.gov)" is better than "Invalid input."

3.3.4 Error Prevention (Legal, Financial, Data) (Level AA) — Manual

For pages that cause legal or financial commitments (like permit applications or payments): submissions must be reversible, data must be checked for errors with a chance to correct, or a confirmation step must be provided before final submission.

Principle 4: Robust

Content must work with current and future assistive technologies.

4.1 Compatible

4.1.2 Name, Role, Value (Level A) — Partial

For all user interface components, the name, role, and state must be programmatically determinable. Custom interactive elements (not standard HTML) need proper ARIA attributes.

Common issue: Custom dropdown menus built with <div> elements instead of <select>, without ARIA roles and states.

Fix: Use standard HTML elements whenever possible. If you must use custom components, add appropriate ARIA roles (role="button", role="menu", etc.), states (aria-expanded, aria-selected), and labels (aria-label).

4.1.3 Status Messages (Level AA) — Partial

Status messages (like "form submitted successfully" or "3 results found") must be communicated to assistive technologies without receiving focus. Use role="status" or aria-live="polite" on the container.

Summary: what automated scanning catches

Out of the 50 criteria above:

• ~12 can be fully detected by automated tools (missing alt text, contrast, page language, skip links, page titles, etc.)
• ~15 can be partially detected (some instances caught, but manual review needed)
• ~23 require manual testing (keyboard navigation, reading order, error handling, etc.)

This is why automated scanning is essential as a first step but not sufficient for full compliance. Start with automated scanning to fix the easy 30–40%, then plan manual testing for the rest.

And whatever you do, don't rely on overlay widgets that promise instant compliance — they don't fix any of these criteria at the source code level.

What to do next

1. Run a free scan to get your baseline
2. Fix the automated findings first — these are the quickest wins
3. Do keyboard testing — Tab through every page, make sure everything works
4. Test with a screen reader — NVDA (free on Windows) or VoiceOver (built into Mac)
5. Set up monthly monitoring to catch regressions when content changes
6. Document everything — your scans, fixes, and ongoing monitoring are your proof of good faith effort

For the full compliance strategy, read our Complete ADA Title II Compliance Guide for Local Governments.

Disclaimer: This checklist is for informational purposes only and does not constitute legal advice. WCAG 2.1 AA includes additional conformance requirements beyond individual success criteria. Consult the official W3C documentation and your municipality's legal counsel for complete guidance.