A practical checklist for meeting WCAG 2.1 Level AA — the standard referenced by ADA lawsuits and the DOJ final rule.
The Web Content Accessibility Guidelines (WCAG) 2.1 is the international standard for making web content accessible to people with disabilities. Published by the World Wide Web Consortium (W3C) in June 2018, WCAG 2.1 builds on the earlier 2.0 version by adding 17 new success criteria, with particular focus on mobile accessibility, people with low vision, and people with cognitive and learning disabilities.
WCAG defines three conformance levels:
Level AA is the standard that matters for legal compliance. It is referenced by the ADA, the DOJ’s final rule on web accessibility (effective April 2026), Section 508, and the European Accessibility Act.
All WCAG success criteria are organized under four foundational principles:
Information and user interface components must be presentable to users in ways they can perceive. This means content cannot be invisible to all of a user’s senses. Key requirements:
User interface components and navigation must be operable by all users. This primarily means keyboard accessibility:
Information and the operation of the user interface must be understandable:
Content must be robust enough to be interpreted reliably by a wide variety of user agents, including assistive technologies:
Normal text (under 18pt / 14pt bold) must have a contrast ratio of at least 4.5:1 against its background. Large text (18pt+ or 14pt+ bold) requires at least 3:1. This is one of the most commonly violated criteria — light gray text on white backgrounds is a frequent offender.
Every <img> element must have an alt attribute. Informative images need descriptive alt text. Decorative images should use alt="" (empty alt) so screen readers skip them. Background images that convey meaning need an accessible alternative.
All interactive elements (links, buttons, form fields, dropdowns, modals) must be fully operable using only the keyboard. Users navigate with Tab, Shift+Tab, Enter, Space, and arrow keys. No functionality should require a mouse.
When an element receives keyboard focus, it must have a visible focus indicator. The default browser outline works, but many sites remove it with outline: none for aesthetic reasons without providing an alternative — this is a serious violation.
Every form input must have a programmatically associated label using the <label> element with a matching for attribute, or using aria-label / aria-labelledby. Placeholder text alone is not sufficient as a label.
When a form validation error occurs, the error must be described in text, the specific field must be identified, and suggestions for correction must be provided when possible. Color alone (e.g., red border) is not sufficient.
Headings must follow a logical hierarchy: one <h1> per page, followed by <h2>, <h3>, etc. Skipping levels (jumping from h1 to h3) creates confusion for screen reader users who navigate by heading structure.
The <html> element must include a lang attribute (e.g., lang="en"). This allows screen readers to select the correct voice and pronunciation rules.
Every page must have a descriptive <title> element that identifies the page’s topic or purpose. Titles should be unique across pages and follow a consistent pattern (e.g., “Page Name | Site Name”).
The purpose of each link must be determinable from the link text alone or from the link text combined with its context. Links that say “Click here” or “Read more” without context are violations.
| Violation | WCAG Criteria | Quick Fix |
|---|---|---|
| Missing alt text | 1.1.1 | Add descriptive alt attributes to all images |
| Low color contrast | 1.4.3 | Increase contrast to 4.5:1 for normal text |
| Missing form labels | 1.3.1 | Add <label> elements with for attributes |
| No focus indicator | 2.4.7 | Never remove outline without providing an alternative |
| Missing page lang | 3.1.1 | Add lang="en" to the <html> element |
| Empty links/buttons | 2.4.4 | Add text content or aria-label |
| Skipped heading levels | 1.3.1 | Use headings in sequential order (h1, h2, h3) |
Automated tools like AccessCheck can detect approximately 30–50% of WCAG issues — primarily structural issues like missing alt text, low contrast, missing labels, and heading violations. However, some criteria require manual testing:
The recommended approach is to start with an automated scan to catch the low-hanging fruit, then follow up with manual testing for the criteria that require human judgment.
The AccessCheck scanner checks any URL against WCAG 2.1 AA criteria in 60 seconds. You get a compliance score (0–100), issues grouped by severity, and specific fix suggestions for each issue. The free tier includes 3 scans per day.
Scan Your Website FreeWCAG 2.1 Level AA is the mid-level conformance standard of the Web Content Accessibility Guidelines version 2.1. It includes all Level A requirements plus additional criteria for color contrast (4.5:1), focus visibility, input assistance, and more. It is the most commonly referenced standard in accessibility laws and lawsuits.
While WCAG itself is a technical standard, not a law, it is referenced by multiple laws and regulations. ADA Title III courts increasingly use WCAG 2.1 AA as the benchmark. The DOJ final rule (April 2026) explicitly adopts WCAG 2.1 AA for state and local government websites.
WCAG 2.1 AA requires a minimum contrast ratio of 4.5:1 for normal text and 3:1 for large text (18pt or 14pt bold). This applies to text against its background color.
Use an automated scanner like AccessCheck to identify common issues, then supplement with manual testing for keyboard navigation, screen reader compatibility, and logical reading order. No automated tool catches 100% of issues.
AccessCheck by NormSuite scans any URL for WCAG 2.1 AA issues in 60 seconds, providing a compliance score, issues grouped by severity, and actionable fix suggestions. The free tier includes 3 scans per day.