What Is the Difference Between WCAG 2.0, 2.1, and 2.2?
WCAG 2.1 adds criteria to 2.0; WCAG 2.2 adds nine and removes Parsing. Check the applicable version and each criterion’s level.
WCAG versions define success criteria at Levels A, AA and AAA. A Level AA target includes all applicable A and AA criteria. Use the version referenced by the applicable law, contract or policy, and assess any additional institutional target separately.
WCAG 2.0 and 2.1
WCAG 2.0 was published in 2008 with 61 criteria. WCAG 2.1, published in 2018, added 17 criteria: five A, seven AA and five AAA. These address needs including mobile input, low vision and cognitive accessibility. Pointer Gestures (2.5.1) is Level A; Orientation (1.3.4), Reflow (1.4.10) and Non-text Contrast (1.4.11) are Level AA.
WCAG 2.2
The W3C WCAG 2.2 standard adds nine criteria and removes 4.1.1 Parsing:
- A: Consistent Help (3.2.6), Redundant Entry (3.3.7).
- AA: Focus Not Obscured—Minimum (2.4.11), Dragging Movements (2.5.7), Target Size—Minimum (2.5.8), Accessible Authentication—Minimum (3.3.8).
- AAA: Focus Not Obscured—Enhanced (2.4.12), Focus Appearance (2.4.13), Accessible Authentication—Enhanced (3.3.9).
Read the complete criterion, including exceptions. A brief description does not replace the normative requirement.
Which version applies?
The DOJ Title II rule sets WCAG 2.1 Level AA requirements for covered state and local government web content and mobile apps, subject to the rule's scope and exceptions. The April 2026 IFR extends the dates to April 26, 2027 for public entities with a population of 50,000 or more and April 26, 2028 for smaller public entities and special district governments. Determine the institution's cohort using DOJ's population rules; enrollment and federal funding alone do not determine it. Existing accessibility obligations continue before those dates.
WCAG 2.2 can be an additional institutional target. Because Parsing was removed from 2.2, a 2.2 evaluation alone should not be described as automatically demonstrating every 2.1 requirement. Assess the referenced standard explicitly.
Australian DDA and DSE obligations are distinct from the US Title II dates; the DSE does not itself prescribe a WCAG version. Check relevant technical guidance, procurement terms and institutional policy.
What a tool can establish
An automated scanner evaluates its implemented checks, not necessarily every criterion in the named version. Document tested and untested areas, use qualified manual evaluation and test the intended tasks.
Aelira Core is beta software. Supported workflows can apply eligible partial fixes and record outcomes, but some inputs need manual work or cannot produce a downloadable remediated file. Review the actual saved output, unresolved findings and content preservation before publication. Automated scores describe implemented checks rather than accessibility conformance. Inspect the public source and release documentation and evaluate a representative authorized sample before planning a rollout.
Aelira Team
•Accessibility EngineersThe Aelira team is building beta accessibility tools for higher education. Institutions can evaluate selected checks and partial fixes on their own files, with human review required before publication.
Related Articles
What Procurement Should Demand in an Accessibility AI Contract: A Due-Diligence Checklist
Eleven proposed due-diligence terms for AI-assisted accessibility procurement. Adapt acceptance, evidence, data-flow and exit commitments to institutional needs.
FERPA, Cloud Inference, and the Data-Sovereignty Question Procurement Should Be Asking
Map document and inference data flows, review FERPA conditions and contract terms, and verify what a self-hosted deployment actually sends outside the institution.
What Accessibility Scores Establish — and Why Review Records Matter
Use scanner scores within their measured scope, and retain review records tied to exact files. Neither a score nor an audit trail guarantees conformance or an investigation outcome.