Accessibility Standards / WCAG

What Is WCAG 2.1 AA?

A plain-language guide for government IT directors and web teams

WCAG 2.1 Level AA is the accessibility standard that the U.S. Department of Justice requires state and local government websites to meet under ADA Title II. If you manage a .gov website, this is the standard your site is measured against.

This guide covers what the standard contains, who it applies to, and what your web team needs to know to achieve and maintain compliance.

What WCAG stands for

WCAG is the Web Content Accessibility Guidelines, published by the World Wide Web Consortium (W3C). The W3C is the international body that develops web standards, including HTML and CSS. WCAG is the specific standard that defines what "accessible" means for websites and web applications.

Version 2.1 was published in June 2018 as an extension of WCAG 2.0 (published in 2008). It adds 17 new success criteria addressing mobile accessibility, low vision, and cognitive disabilities that were not adequately covered in the original standard.

When the DOJ finalized the ADA Title II rule in April 2024, it adopted WCAG 2.1 Level AA as the specific technical standard. This is the version your government website must conform to.

What Level AA means

WCAG defines three conformance levels:

Level A — The minimum. Addresses the most severe barriers that would make content completely unusable for some users. Example: providing text alternatives for images.
Level AA — The target for compliance. Covers the majority of real-world accessibility barriers without imposing the most burdensome requirements. Example: text contrast must be at least 4.5:1.
Level AAA — The highest standard. Includes requirements that are often impractical for entire sites, such as providing sign language interpretation for all audio content. Not required by ADA Title II.

Level AA is the legally required target. It includes all Level A criteria plus additional requirements. When someone says "WCAG 2.1 AA compliant," they mean the site meets both Level A and Level AA criteria.

The four POUR principles

Every WCAG criterion falls under one of four principles. Understanding these principles helps web teams think about accessibility systematically rather than as a checklist of isolated fixes.

Perceivable

Users must be able to perceive all content. This means providing text alternatives for images, captions for video, sufficient color contrast, and the ability to resize text without breaking the layout. If content can only be perceived visually, blind users are excluded. If it can only be perceived through audio, deaf users are excluded.

Operable

Users must be able to navigate and interact with all functionality. This means every interactive element must work with a keyboard alone, users must have enough time to complete tasks, content must not cause seizures, and navigation must be consistent and predictable. If a dropdown menu only works with a mouse hover, keyboard users cannot access those pages.

Understandable

Content and interface behavior must be understandable. This means declaring the page language so screen readers pronounce words correctly, labeling form fields clearly, providing error messages that explain what went wrong and how to fix it, and maintaining consistent navigation across pages.

Robust

Content must work reliably with current and future assistive technologies. This means using valid, semantic HTML, ensuring ARIA attributes are used correctly, and not relying on non-standard markup that screen readers cannot interpret. A page built with proper heading hierarchy and standard form elements is inherently more robust than one using custom widgets without ARIA roles.

Key success criteria for government websites

WCAG 2.1 Level AA contains 50 success criteria. These are the ones that most commonly cause failures on government websites, based on our scanning data:

Criterion	Requirement	Common failure
1.1.1	Non-text content has text alternatives	Staff photos, event banners, and decorative images missing alt text
1.3.1	Info and relationships are programmatically determinable	Form inputs without associated labels, tables without headers
1.4.3	Text has at least 4.5:1 contrast ratio	Gray text on white backgrounds, light blue links on gray
2.4.4	Link purpose is clear from the link text	"Click here" and "Read more" links without context
4.1.2	UI components have accessible names and roles	Custom buttons and menus missing ARIA labels
1.4.11	Non-text contrast at least 3:1	Form field borders, icons, and focus indicators with insufficient contrast (new in 2.1)
2.5.3	Accessible name includes the visible label	Buttons with ARIA labels that don't match their visible text (new in 2.1)

How WCAG 2.1 differs from WCAG 2.0

WCAG 2.1 is a superset of WCAG 2.0. Every criterion in 2.0 is still in 2.1. The difference is 17 additional criteria addressing gaps in three areas:

Mobile accessibility

WCAG 2.0 was written when most web access happened on desktops. Version 2.1 adds criteria for touch targets (minimum 44x44 CSS pixels at Level AAA, though Level AA addresses this through operable guidelines), pointer gestures (complex gestures must have single-pointer alternatives), and motion actuation (shake-to-undo must have a non-motion alternative).

Low vision

New criteria require that text spacing can be adjusted without breaking the layout (1.4.12), that content reflows to a single column at 320px width without horizontal scrolling (1.4.10), and that content displayed on hover or focus is dismissible and persistent (1.4.13).

Cognitive accessibility

WCAG 2.1 adds requirements for consistent identification of purpose for input fields (1.3.5) so browsers can auto-fill form data, and for accessible labels matching visible labels (2.5.3) so voice control users can activate controls by speaking their visible name.

For government websites that were previously targeting WCAG 2.0, the upgrade to 2.1 means auditing for these 17 additional criteria. The reflow requirement (1.4.10) and text spacing requirement (1.4.12) are the ones most likely to require template-level changes.

Testing tools

No single tool catches all WCAG violations. Automated scanning reliably detects 30-40% of issues. The remaining 60% require manual testing. A practical testing approach for government web teams combines both:

Automated tools

axe-core — The open-source engine used by A11yGov, Chrome DevTools, and most major accessibility scanners. It runs against the live DOM and catches structural violations like missing alt text, insufficient contrast, and missing form labels.
Lighthouse — Built into Chrome, runs a subset of axe-core rules plus performance and SEO checks. Good for individual page audits during development.
WAVE — A browser extension from WebAIM that provides a visual overlay showing accessibility issues in context. Useful for training web editors on what to look for.

Manual testing

Keyboard navigation — Tab through every page using only the keyboard. Can you reach every interactive element? Can you see where focus is? Can you activate buttons and links with Enter or Space?
Screen reader testing — Test with NVDA (free, Windows), JAWS (commercial, Windows), or VoiceOver (built into macOS and iOS). Listen to how the page reads. Are headings logical? Are images described? Do forms announce their labels?
Zoom and reflow — Zoom the browser to 200% and 400%. Does content reflow without horizontal scrolling? Is all text still readable?

What compliance actually requires

Under the ADA Title II final rule, compliance means that your web content conforms to WCAG 2.1 Level AA. For state and local government entities with populations of 50,000 or more, the compliance deadline was April 24, 2026. For entities with populations under 50,000, the deadline is April 24, 2027.

Conformance is measured per page. A single non-conforming page means the site as a whole is not fully compliant. In practice, the DOJ evaluates good-faith effort: whether you are testing, documenting, and remediating issues on a reasonable timeline.

The most effective approach is continuous monitoring. Running automated scans regularly catches regressions introduced by site updates, CMS changes, and new content. Manual audits should be conducted at least annually and whenever significant site changes are made.

Free compliance scan

Check your government website now

Enter your .gov URL on our homepage and receive a WCAG 2.1 AA compliance score in 60 seconds. No account required. The scan uses axe-core to identify the most common violations and provides specific remediation guidance.

Run a Free Scan