WCAG 2.2 Compliance: Levels, New Criteria and How Laws Use It

WCAG compliance is the practical meaning of "accessible" for websites and applications. The Web Content Accessibility Guidelines, published by the W3C, describe how to make digital content usable by people who are blind or have low vision, are deaf or hard of hearing, have motor, cognitive or speech disabilities, or use assistive technologies such as screen readers, switch devices and voice control. They are written as testable success criteria, which is why laws and courts around the world use them as the benchmark.

The current version, WCAG 2.2, became a W3C Recommendation in October 2023 and added nine success criteria focused on keyboard focus, touch targets, dragging, consistent help and accessible authentication. WCAG itself is voluntary, but the European Accessibility Act, US Section 508, the ADA Title II rule and India's accessibility standards all require conformance to WCAG or standards built on it. This guide explains the structure, the levels, what changed in 2.2, how to test, how to report conformance, and how software teams can build accessibility in rather than bolting it on.

What is WCAG?

WCAG is a technical standard from the W3C's Web Accessibility Initiative. It applies to web content in the broad sense: websites, web applications, documents delivered on the web, and, through guidance documents, mobile apps and other software. It is built in layers:

• Four principles: content must be perceivable, operable, understandable and robust (often abbreviated POUR).
• Thirteen guidelines under those principles, such as "text alternatives", "keyboard accessible" and "input assistance".
• Success criteria (86 in WCAG 2.2): testable statements, each assigned a level A, AA or AAA.
• Sufficient and advisory techniques and "Understanding" documents explaining how to meet each criterion.

WCAG 2.2 is backwards compatible: content that conforms to 2.2 also conforms to 2.1 and 2.0, with one exception (criterion 4.1.1 Parsing was removed as obsolete). It was also published as an international standard, ISO/IEC 40500:2025.

History and why WCAG exists

WCAG 1.0 was published in 1999, early in the web's history, as a set of checkpoints. WCAG 2.0 (2008) introduced technology-neutral, testable success criteria and was adopted as ISO/IEC 40500:2012 and by many laws. WCAG 2.1 (2018) added criteria for mobile, low vision and cognitive disabilities. WCAG 2.2 (2023) added further criteria. W3C is developing WCAG 3.0 with a different structure, but it is a working draft and not yet suitable for legal reference.

The purpose is equal access. Around the world, a significant share of people live with disabilities, and many more have temporary or situational impairments. Accessible design also improves usability for everyone, for example clear forms, readable contrast and keyboard shortcuts.

Conformance levels

Level	Meaning	Typical use
A	The most basic requirements; failing them makes content impossible to use for some groups	Minimum; never sufficient alone for legal compliance
AA	Includes A plus criteria addressing the most common barriers	The target in most laws and policies
AAA	Includes AA plus enhanced criteria	Applied selectively; W3C does not recommend requiring AAA for entire sites

Conformance applies to full pages and complete processes: if a checkout process has an inaccessible step, the whole process does not conform.

Key requirements by principle

Perceivable

• Text alternatives for non-text content such as images, icons and charts.
• Captions for prerecorded and live audio in video, and audio description or alternatives.
• Content that can be presented in different ways without losing meaning: proper headings, lists, tables and labels in code, a meaningful reading order, and not relying on shape, colour or position alone.
• Colour contrast of at least 4.5:1 for normal text and 3:1 for large text and user interface components at AA.
• Text that can be resized and content that reflows at narrow widths without horizontal scrolling.

Operable

• Everything usable with a keyboard, with no keyboard traps and a visible focus indicator.
• Enough time to read and use content, with ways to extend or turn off time limits.
• No content that flashes more than three times per second.
• Ways to navigate: skip links, page titles, logical focus order, descriptive link text and headings.
• Input modalities: alternatives to complex gestures and dragging, adequate target sizes, and labels that match visible text.

Understandable

• The language of the page identified.
• Predictable behaviour: no unexpected changes of context on focus or input, consistent navigation and identification.
• Input assistance: clear labels and instructions, error identification and suggestions, error prevention for legal and financial transactions.

Robust

• User interface components expose name, role and value to assistive technologies, typically through correct HTML and, where needed, ARIA.
• Status messages announced to assistive technologies without moving focus.

What is new in WCAG 2.2

Criterion	Level	In short
2.4.11 Focus Not Obscured (Minimum)	AA	Focused elements are not entirely hidden by sticky headers, banners or other content
2.4.12 Focus Not Obscured (Enhanced)	AAA	No part of the focused element is hidden
2.4.13 Focus Appearance	AAA	Focus indicators meet size and contrast requirements
2.5.7 Dragging Movements	AA	Functions that use dragging have a single-pointer alternative
2.5.8 Target Size (Minimum)	AA	Pointer targets are at least 24 by 24 CSS pixels, with exceptions
3.2.6 Consistent Help	A	Help mechanisms appear in a consistent place across pages
3.3.7 Redundant Entry	A	Information already entered is not requested again in the same process, with exceptions
3.3.8 Accessible Authentication (Minimum)	AA	Login does not rely on cognitive function tests such as remembering or transcribing, unless alternatives or help are provided; allowing paste and password managers helps
3.3.9 Accessible Authentication (Enhanced)	AAA	Stricter version without some exceptions

For developers, the most common 2.2 fixes are sticky headers that cover focused elements, small icon buttons, drag-only interfaces (sliders, sortable lists, maps) and login flows that block paste or rely on puzzles.

Which laws reference WCAG?

• European Union: the European Accessibility Act and the Web Accessibility Directive for public sector bodies rely on the harmonised standard EN 301 549, which incorporates WCAG 2.1 Level AA for web content.
• United States: Section 508 standards incorporate WCAG 2.0 Level AA for federal ICT; the Department of Justice's 2024 ADA Title II rule adopts WCAG 2.1 Level AA for state and local governments; courts frequently reference WCAG in ADA Title III cases against businesses.
• United Kingdom: public sector accessibility regulations reference WCAG 2.2 AA in government guidance.
• India: the Rights of Persons with Disabilities Act, 2016, the Guidelines for Indian Government Websites and the Indian Standard IS 17802 on ICT accessibility build on WCAG.
• Canada, Australia and many others reference WCAG in public sector or general accessibility laws.

Laws often reference an older version (2.0 or 2.1). Building to WCAG 2.2 AA meets those as well, apart from the removed Parsing criterion, which modern code rarely fails.

How to achieve WCAG conformance step by step

1. Set the target: usually WCAG 2.2 Level AA, plus any law-specific requirements.
2. Audit the current state with automated tools and manual testing on key user journeys.
3. Prioritise barriers that block tasks: inaccessible forms, keyboard traps, missing labels, low contrast, unlabelled controls.
4. Fix the design system first: colours, focus styles, buttons, form fields, modals, menus and tables, so every page inherits accessible components.
5. Train designers, developers and content authors on their part of WCAG.
6. Add accessibility to the definition of done and code review, with automated checks in CI.
7. Test with assistive technologies: screen readers, keyboard only, zoom and voice control, and ideally with disabled users.
8. Publish an accessibility statement with conformance status, known issues and a contact for feedback.
9. Produce an Accessibility Conformance Report if you sell to organisations that require one.
10. Monitor and retest after releases and redesigns.

Accessibility in an agile team

Accessibility fails most often when it is treated as a final audit. Teams that get it right spread the work across roles:

• Product owners include accessibility in acceptance criteria, for example "the date filter is fully usable with a keyboard and announced by screen readers".
• Designers check contrast, focus states, target sizes and reading order in designs, and annotate headings, landmarks and labels for developers.
• Developers use accessible components, semantic HTML and automated checks, and test new features with a keyboard before review.
• Testers include screen reader and zoom checks in regression testing for key journeys.
• Content authors write meaningful alternative text, descriptive links and clear headings, and produce accessible documents.

A short accessibility checklist in the pull request template and a small set of assistive technology tests per release keep regressions from creeping back after an audit.

Documentation you will need

• Accessibility policy and target standard.
• Audit reports with issues mapped to success criteria and their status.
• Accessibility statement on the website or app.
• Accessibility Conformance Report (ACR), often using the VPAT template, for products sold to public bodies and enterprises.
• Design system documentation with accessibility guidance.
• Training records and test plans.

Testing, audits and certification

There is no official WCAG certification from W3C. Conformance is claimed by the owner, ideally supported by an expert audit. Automated tools detect only a portion of issues, so manual testing with keyboard and screen readers is essential. Some organisations obtain third-party audit letters, and individual professionals can hold accessibility certifications, but these are not W3C certifications.

Timeline and cost considerations

Fixing an existing large site can take months, especially when issues are in shared components or third-party widgets. New projects that build accessibility into design and components from the start cost far less. Cost factors include audits, remediation, design system work, training, assistive technology testing and ongoing monitoring.

Benefits and consequences of non-compliance

Accessible products reach more customers, improve usability and SEO structure, and reduce legal risk. In many markets, inaccessible sites and apps face complaints, regulatory enforcement and lawsuits. In the US, thousands of digital accessibility lawsuits are filed each year under the ADA and state laws; in the EU, national authorities enforce the European Accessibility Act with penalties set by each member state.

Common mistakes and challenges for IT companies

• Relying on overlays or widgets that claim to fix accessibility automatically. They do not make a site conform and have drawn criticism and lawsuits.
• Automated testing only.
• Custom components without keyboard and screen reader support: dropdowns, date pickers, modals, carousels.
• Removing focus outlines for visual design.
• Icon-only buttons without accessible names.
• Inaccessible PDFs and documents linked from accessible pages.
• Third-party embeds (chat, payments, maps) that break conformance.

Best practices, tools and technologies

• Use semantic HTML first; add ARIA only when needed and correctly.
• Build an accessible component library and test it once, thoroughly.
• Add automated accessibility checks to CI and linting.
• Test with NVDA or JAWS on Windows, VoiceOver on macOS and iOS, and TalkBack on Android.
• Check colour contrast in the design tool before development.
• Write content in plain language with clear headings and link text.

We design and build to WCAG 2.2 AA when clients ask, through our UI/UX design and web application development services.

How WCAG relates to other frameworks

Law or standard	Relationship
European Accessibility Act	EU law; uses EN 301 549, which incorporates WCAG 2.1 AA.
Section 508	US federal ICT standards incorporating WCAG 2.0 AA.
ADA	Title II rule adopts WCAG 2.1 AA; courts reference WCAG in Title III cases.
EN 301 549	European standard for ICT accessibility covering web, software, documents and hardware.
ISO/IEC 40500	International standard publication of WCAG.

Real-world implementation examples

Government design systems, such as the UK's GOV.UK Design System and the US Web Design System, publish accessible components tested with assistive technologies, which show how building accessibility into components scales across many services. Large e-commerce and banking sites that redesigned around accessible design systems have reduced both complaints and maintenance effort.

An illustrative case for a SaaS dashboard: an enterprise customer requests an ACR. An audit finds custom dropdowns that are not keyboard accessible, icon buttons without names, charts without text alternatives and low-contrast status colours. The team rebuilds components on accessible patterns, adds data table alternatives for charts, adjusts the colour palette, and publishes an ACR showing WCAG 2.2 AA support with two partially supported criteria and a remediation plan.

Next steps

1. Set WCAG 2.2 AA as your target.
2. Audit key user journeys with automated and manual testing.
3. Fix shared components and the design system first.
4. Build accessibility into design, development and QA.
5. Publish an accessibility statement and produce an ACR if customers need one, and keep both current after each major release.

Frequently asked questions

What is the latest version of WCAG?

WCAG 2.2, a W3C Recommendation since October 2023. WCAG 3.0 is a working draft.

Is WCAG a law?

No. It is a W3C standard. Many laws and regulations require conformance to WCAG or to standards based on it.

Which WCAG level should we aim for?

Level AA, which is the target referenced by most laws and procurement requirements.

What changed in WCAG 2.2?

Nine new success criteria covering focus visibility, dragging, target size, consistent help, redundant entry and accessible authentication, and the removal of 4.1.1 Parsing.

Is there a WCAG certification?

No official one. Organisations claim conformance and support it with audits and Accessibility Conformance Reports.

Do accessibility overlays make a site WCAG compliant?

No. Overlays cannot fix underlying code and content issues, and relying on them can increase legal risk.

Does WCAG apply to mobile apps?

WCAG is written for web content, but W3C guidance explains how it applies to mobile, and EN 301 549 applies WCAG-based requirements to software and apps.

What is a VPAT?

The Voluntary Product Accessibility Template, a format for producing an Accessibility Conformance Report describing how a product supports accessibility standards.

How much of WCAG can automated tools test?

Only part of it. Many criteria, such as meaningful alternative text and logical focus order, need human judgement.

Does building to WCAG 2.2 also satisfy laws that reference 2.1?

Yes, in practice. WCAG 2.2 includes all 2.1 criteria except 4.1.1 Parsing, which was removed as obsolete.