WCAG 2.1 AA is the technical standard specified by the Department of Justice’s Title II web and mobile accessibility rule for covered state and local government entities. In that Title II context, WCAG 2.1 Level AA is the version named by the rule.
For ADA Access Group commercial accessibility work, the default technical target is WCAG 2.2 AA. We use WCAG 2.1 AA when a contract or regulation specifically requires that version. That commercial default should not be confused with a universal legal rule requiring every private website to conform to WCAG 2.2.
This article compares WCAG 2.1 AA and WCAG 2.2 so teams can identify which standard applies without creating another overlapping WCAG article. The existing Level AAA article remains a narrower child topic about when to go beyond AA.
WCAG does not prescribe a single website design. Instead, it defines accessibility outcomes that content and functionality need to meet.
What Does WCAG 2.1 AA Mean?
WCAG includes three conformance levels:
- Level A: foundational accessibility requirements.
- Level AA: additional requirements addressing significant and common accessibility barriers.
- Level AAA: additional criteria that provide a higher level of accessibility for particular needs and situations.
To conform to WCAG 2.1 at Level AA, content needs to satisfy the applicable Level A and Level AA success criteria and meet WCAG's conformance requirements.
Passing only selected AA criteria while failing applicable Level A requirements would not constitute Level AA conformance.
The Four WCAG Principles: POUR
WCAG organizes accessibility around four principles commonly abbreviated as POUR:
Perceivable
Information and user-interface components need to be presented in ways users can perceive.
Examples include:
- text alternatives for meaningful non-text content;
- captions for applicable media;
- adaptable structure and relationships;
- sufficient contrast; and
- content that can be resized or presented without unnecessary loss of information.
Operable
Users need to be able to operate the interface.
Examples include:
- keyboard accessibility;
- appropriate focus behavior;
- ways to navigate and identify content;
- consideration of timing requirements; and
- interaction patterns that do not create unnecessary barriers.
Understandable
Information and operation of the user interface should be understandable.
Examples include:
- identifying page language;
- predictable interface behavior;
- clear labels and instructions;
- useful error identification; and
- assistance when users need to correct input.
Robust
Content should be implemented so it can be interpreted reliably by user agents and assistive technologies.
This includes using appropriate semantic markup and exposing the names, roles, values, and states of interface components correctly.
Is WCAG 2.1 Still Valid in 2026?
Yes.
WCAG 2.0, WCAG 2.1, and WCAG 2.2 remain W3C Recommendations. WCAG 2.2 did not simply invalidate WCAG 2.1.
W3C encourages organizations to use the latest WCAG version to improve future applicability of their accessibility work. At the same time, laws, regulations, procurement standards, and contracts may continue to reference a specific earlier version.
That means a team can encounter a requirement that formally references WCAG 2.1 even while choosing to account for WCAG 2.2 in its internal design and testing program.
What Is WCAG 2.2, the Current WCAG 2 Recommendation?
WCAG 2.2 extends WCAG 2.1 with additional success criteria intended to address accessibility needs including those related to cognitive disabilities, low vision, and mobile interaction.
WCAG 2.2 added nine success criteria:
- 2.4.11 Focus Not Obscured (Minimum) — Level AA;
- 2.4.12 Focus Not Obscured (Enhanced) — Level AAA;
- 2.4.13 Focus Appearance — Level AAA;
- 2.5.7 Dragging Movements — Level AA;
- 2.5.8 Target Size (Minimum) — Level AA;
- 3.2.6 Consistent Help — Level A;
- 3.3.7 Redundant Entry — Level A;
- 3.3.8 Accessible Authentication (Minimum) — Level AA; and
- 3.3.9 Accessible Authentication (Enhanced) — Level AAA.
WCAG 2.2 also treats WCAG 2.1 Success Criterion 4.1.1 Parsing as obsolete and removes it from WCAG 2.2.
Does WCAG 2.2 Replace WCAG 2.1?
Not in the sense that WCAG 2.1 became invalid.
W3C describes the WCAG 2 versions as backward compatible. Content that conforms to WCAG 2.2 also conforms to WCAG 2.1 and WCAG 2.0, subject to the treatment of the obsolete Parsing criterion.
This makes WCAG 2.2 a useful target for organizations that want to account for the newest WCAG 2 success criteria while also supporting environments that reference WCAG 2.1.
Should a New Website Target WCAG 2.1 AA or WCAG 2.2 AA?
If an organization is choosing a modern accessibility target without a requirement limiting it to an older version, WCAG 2.2 AA is generally the more forward-looking technical target because W3C recommends using the latest version.
However, the correct answer depends on why the organization is establishing the target.
Ask:
- Does a law or regulation identify a particular WCAG version?
- Does a contract specify WCAG 2.1 or 2.2?
- Does a customer procurement requirement define a version?
- Does an internal accessibility policy define a standard?
- Does the organization need to report conformance against a specific benchmark?
The technical target should be documented clearly rather than using the generic phrase “WCAG compliant” with no version or level.
Which WCAG Version Does the ADA Title II Rule Require?
The Department of Justice's web and mobile accessibility rule for state and local governments under ADA Title II specifically uses WCAG 2.1 Level A and Level AA.
As of September 2026, the current general compliance dates are April 26, 2027 for public entities with populations of 50,000 or more and April 26, 2028 for smaller public entities and special district governments.
The fact that W3C recommends WCAG 2.2 does not change the version incorporated into the DOJ Title II rule.
Does ADA Title III Require WCAG 2.1 AA for Every Private Website?
Be careful with this statement.
ADA Title III applies to many private businesses that are open to the public, and the Department of Justice has consistently taken the position that the ADA's requirements apply to goods and services offered by covered public accommodations on the web.
However, the DOJ's general web accessibility guidance for businesses does not establish a universal federal regulation requiring every private business website to meet WCAG 2.1 AA by a single nationwide deadline.
WCAG remains an important technical framework for evaluating and improving accessibility, but a technical accessibility standard should not automatically be presented as a legal conclusion.
Organizations with questions about specific legal obligations should consult qualified counsel.
What Does WCAG AA Actually Cover?
A WCAG AA evaluation is much broader than running a contrast checker or adding alternative text to images.
Depending on the content and functionality, testing may address:
- text alternatives;
- captions and media alternatives;
- semantic structure;
- content relationships;
- orientation and presentation;
- color and contrast;
- text resizing and reflow;
- keyboard access;
- keyboard traps;
- focus visibility;
- focus order;
- page titles;
- link purpose;
- headings and labels;
- pointer gestures;
- accessible names;
- language;
- consistent navigation;
- form labels and instructions;
- error identification;
- error prevention in applicable contexts;
- status messages; and
- programmatic compatibility with assistive technology.
WCAG 2.2 adds further considerations including focus not being obscured, dragging alternatives, target size, redundant entry, and accessible authentication.
Can an Automated Scanner Determine WCAG AA Conformance?
No.
Automated tools are extremely useful for finding machine-testable problems, but not every WCAG success criterion can be evaluated automatically.
W3C states that evaluation tools cannot check every aspect of accessibility and that human judgment is required.
For example, an automated tool may determine that an image contains an alt attribute but not whether the alternative text appropriately communicates its purpose.
Likewise, a scanner may inspect individual properties of a custom component without determining whether the complete interaction works logically with a keyboard and screen reader.
Read our guide to automated vs manual accessibility testing for a deeper explanation.
How to Evaluate a Website Against WCAG
1. Define the target
Document the WCAG version and conformance level you are evaluating. For example, “WCAG 2.2 Level AA” is much more precise than simply saying “WCAG compliant.”
2. Define the scope
Identify representative templates, components, and critical workflows rather than testing only the homepage.
3. Run automated testing
Use appropriate tools to identify potential machine-detectable barriers and repeated implementation patterns.
4. Perform manual keyboard testing
Evaluate operation, focus order, focus visibility, dialogs, menus, forms, custom controls, and important tasks.
5. Perform appropriate assistive-technology testing
Use screen readers and other relevant platform accessibility features to evaluate how content and controls are exposed.
6. Document findings against specific success criteria
Each confirmed issue should be tied to the relevant requirement and include enough information for a developer or content owner to reproduce and understand the barrier.
7. Remediate systematically
Fix shared templates and reusable components when possible so one remediation can improve multiple pages.
8. Retest
Verify significant fixes against the original condition. Do not assume a code change resolved the accessibility barrier without validation.
Common WCAG Problems to Prioritize
Every website is different, but high-impact accessibility work often involves areas such as:
- keyboard-inaccessible navigation;
- missing or poorly managed focus;
- forms without clear labels;
- inaccessible form errors;
- custom controls without correct accessibility semantics;
- dialogs with incorrect focus behavior;
- insufficient text contrast;
- meaningful images without useful alternatives;
- unlabeled buttons and links;
- inaccessible authentication flows;
- content that breaks when text is enlarged;
- inaccessible tables; and
- third-party widgets that block critical tasks.
The best remediation order should consider both technical severity and the real user journey affected by the issue.
WCAG Conformance Is Not a One-Time Checkbox
Even a well-tested website changes over time.
New pages are published. Components are redesigned. Plugins are upgraded. Marketing tools are added. Forms change. Third-party services are replaced.
Accessibility therefore works best as part of the normal product lifecycle:
- accessible design;
- accessible development;
- automated checks;
- manual testing;
- remediation;
- retesting; and
- ongoing monitoring and governance.
Frequently Asked Questions
Is WCAG 2.1 obsolete?
No. WCAG 2.1 remains a W3C Recommendation and is still referenced by important accessibility requirements, including the DOJ's ADA Title II web and mobile accessibility rule.
Is WCAG 2.2 the newest WCAG 2 standard?
Yes. WCAG 2.2 is the latest WCAG 2 Recommendation, and W3C encourages organizations to use the latest version when possible.
Does meeting WCAG 2.2 also meet WCAG 2.1?
WCAG 2.2 was designed to be backward compatible with WCAG 2.1. W3C states that content conforming to WCAG 2.2 also conforms to WCAG 2.1, with WCAG 2.2 treating Success Criterion 4.1.1 Parsing as obsolete.
Does WCAG conformance guarantee ADA compliance?
No technical audit should be presented as a universal legal guarantee. WCAG can provide a defined technical accessibility benchmark, while legal obligations depend on the applicable law, regulation, organization, jurisdiction, and circumstances.
Can an automated accessibility tool certify WCAG AA conformance?
An automated tool alone cannot evaluate every aspect of WCAG conformance. Manual evaluation and human judgment are required for criteria and interactions that cannot be determined automatically.
Need a WCAG Accessibility Audit?
If you need to understand how your website performs against a defined WCAG target, start with a structured accessibility evaluation rather than relying on a scanner score alone.
ADA Access Group provides WCAG accessibility audits, remediation support, and retesting using a combination of automated and manual evaluation.
You can also start with our free website accessibility scan to identify potential automated findings before deciding whether a deeper review is appropriate.
ADA Access Group provides technical accessibility services, not legal advice. Accessibility testing does not guarantee compliance with every law or eliminate the possibility of future claims.