How to Test Your Website Against WCAG 2.2 Guidelines?

There is a person behind every click, scroll, and tap, and they are trying to get something done. For some, the web doesn't always help them meet them halfway. This is not a flaw in people; it is a flaw in how we create websites.

WCAG 2.2 is about to change that. With the release of WCAG 2.2, we are introducing even more updates to better reflect the needs of even more users of the web. We added changes for people with low vision, memory, or attention issues, and those who use touch devices.

Here you will learn how to test your site against WCAG 2.2 with care, clarity, and confidence!

Understand the Basics of WCAG 2.2

If you want to make your website accessible, you need to understand the guidelines against which you’re testing. 

The Web Content Accessibility Guidelines (WCAG) are the standards you and your developers are trying to meet in order to allow people with all types of abilities to leverage your digital content. 

WCAG has three levels of guidelines:

• Level A - the most basic requirements. Sites that fail A are typically so unusable that they frustrate some people trying to use them at all.
• Level AA - the most commonly used standard. Level AA accesses the balance between usability and practicality and is frequently a legal requirement in many countries.
• Level AAA - the highest level that you can achieve. It would be ideal, but not every site or person will be able to achieve it.

WCAG 2.2 has added nine success criteria for a total of 78, and is an addendum to WCAG 2.1 and will particularly improve the experience for persons with cognitive impairments, low vision and those who use touch devices.

WCAG 2.2 New Success Criteria

The web should be a sphere where people do not feel lost, closed out, or left behind. The new success criteria in WCAG 2.2 seek to address smaller, meaningful problems real people encounter every day. 

Let's take a look at all nine of them, not just as rules but as human experiences. 

Success Criterion	Name	Level
2.4.11	Focus Appearance (Minimum)	AA
2.4.12	Focus Not Obscured (Minimum)	AA
2.4.13	Focus Not Obscured (Enhanced)	AAA
2.5.7	Dragging Movements	AA
2.5.8	Target Size (Minimum)	AA
3.2.6	Consistent Help	A
3.3.7	Redundant Entry	A
3.3.8	Accessible Authentication (Minimum)	AA
3.3.9	Accessible Authentication (Enhanced)	AAA

What’s the Difference Between WCAG 2.1 and WCAG 2.2?

When WCAG 2.1 came out, it addressed some important gaps for people using mobile devices, for people with low vision, and for people with cognitive disabilities. It was a step forward. 

WCAG 2.2 continues that step forward. It doesn't supersede WCAG 2.1; it builds upon it. So if you are already meeting the WCAG 2.1 standards, you are almost there. 

But 2.2 introduces nine new success criteria to make the web more usable, especially for people who are often unnoticed in the digital space.

Here’s the simple difference between WCAG 2.1 and WCAG 2.2 breakdown:

WCAG 2.1	WCAG 2.2
Released in 2018	Released in 2023
Added 17 success criteria to WCAG 2.0	Adds 9 new success criteria to WCAG 2.1
Focused on mobile accessibility, low vision, and cognitive disabilities	Deepens support for those same users with even more targeted guidance
Level AA compliance is required by many laws	WCAG 2.2 is not yet legally required everywhere, but following it shows a commitment to best practices

Prepare for Testing

Before you begin testing your site for WCAG 2.2 compliance, you'll want to be patient and plan things out.

Here's how to prepare carefully and wisely:

1. Make a Testing Plan

A testing plan will help you:

• Identify clear objectives (for example: "The objective is to meet WCAG 2.2 Level AA")
• Clarify which tools and procedures to use
• Identify the people who will be involved (developers/QA/designers/content writer/accessibility consultant)

2. Identify which pages and components to test

Not every page on your site will need to be tested at the same level of depth, but there are a couple of areas you need to focus on, like:

• Homepage
• Navigation menus
• Forms (contact/checkout/logins);
• Interactive components (buttons, sliders, accordions);
• Dynamic content (pop-ins/pop-ups; modals; on-screen errors, warnings, etc.)

Start with the areas on your site that users will be interacting with the most. These areas will most often contain the majority of your site's accessibility risk.

3. Know Your Users

It is important to know who your users are and how they will likely engage with your content:

• Screen reader users because they are unable to see the screen
• Keyboard-only users, because they cannot use a mouse
• Users with cognitive disabilities require clarity and simplicity
• Users on mobile devices require larger target areas and less clutter
• The more you know about your audience, the more sense your testing will make.

4. Establish a baseline with WCAG 2.1 (if you have not already)

If you have not tested your site against WCAG 2.1, then do that first. Most of the criteria in 2.2 ultimately build on the same criteria from 2.1, so if you can reach 2.1 Level AA, you will ultimately get quite a few of the critical needs and have a much smoother path to 2.2.

Test Your Website Against WCAG 2.2 Guidelines in Three Ways

 

To measure compliance with WCAG 2.2 on your website, you need to cover a mixture of methods, automated tools, manual checks, and user testing. Each of these methods is useful for identifying different accessibility issues. 

1. Automated Testing Tools

Automated tools are great for identifying common accessibility problems quickly. They examine your site and report information about errors, such as missing alt text, defective heading structure, and colour contrast issues.

Benefits:

• Fast and easy to run
• Catch many technical mistakes
• Good for ongoing checks

Limitations:

• Cannot evaluate context/user experience
• Does not report keyboard navigation issues and ambiguity in link labels

Recommendations:

• Axe DevTools – A browser extension that provides clear reports
• WAVE – A visual tool that highlights  accessibility mistakes and alerts
• Lighthouse – Built into Chrome DevTools and includes a comprehensive look at accessibility audits

2. Manual Testing

Manual testing fills in the blanks that automated testing leaves, and it lets you think about how a user uses your site, whether they use an assistive technology, whether they use a mouse, etc.

Some key areas to check:

• Keyboard navigation - Ensure that all elements are reachable and usable in a sensible tab order.
• Focus indicators - You want an obvious outline when moving through your elements.
• Screen reader compatibility - Test with NVDA, VoiceOver, or JAWS
• Color contrast and visual cues - Readability and comprehension all exist without colour being the only cue.
• Touch targets - Pull buttons and links in line with the WCGA 2.2 findings for size
• Consistent navigation - Menus, headers, and layout should have some sort of pattern for the user to follow.

New WCAG 2.2 guidelines - Check to make sure the new guidelines, like Focus Appearance and Dragging Movements, are correct manually.

3. Test with Real Users

Testing with people who use assistive technologies or people with disabilities gives you the best representation of how usable your site truly is.

Why it matters:

• Identifies barriers that auto-tools and manual checks might miss
• A way to ground truth your accessibility efforts in practice, in the wild.

How to do it:

• Recruit participants with a range of disabilities and tech preferences
• Set common tasks (e.g., filling out a form, navigating menus)
• Observe interactions to identify friction points
• Collect feedback on clarity, comfort, and usability
• Combine findings with technical audit results for a full picture

Document Issues and Fixes

Finding accessibility issues is just the first step. Tracking and resolving them is where the real work happens.

Record All Issues

As with everything in your accessibility testing process, record every issue you identify. Each issue should include a short description, the page or element, the associated WCAG 2.2 criteria, and the severity of any impact. 

It is important to maintain a good record to keep your team focused and to make sure nothing critical is overlooked.

Use a Checklist

Having a WCAG checklist makes the process easier to maintain. A checklist will help you record what has been tested and what you still need to test. 

As you make your way through the site, you can either pass, fail, or state it does not apply to each guideline. This will maintain structure, particularly if many people are working on the testing.

Work Together to Fix Issues

Fixing accessibility issues is rarely done alone. Developers solve code problems. Designers fix layout and contrast issues. 

Content editors improve clarity in text, labels, headings, and much more. Working together makes this process more streamlined and effective.

Retest Issues that were Fixed

Once the issue is fixed, you should retest it. You want to make sure it fixed the problem that it was intended to fix and hadn’t caused another issue. 

Testing again is a way to retain confidence in your work and be sure that you have made long-term improvements in accessibility.

Conclusion

Testing against WCAG 2.2 helps ensure that your site works for everyone, including those who use assistive technologies or navigate the world differently. 

Accessibility testing takes a mix of tools, thoughtful manual checks, and real user feedback, and can feel daunting at first, but taking baby steps is better than not taking any steps. 

Not sure where to begin?

Start with an easy and free accessibility audit for your website using Accesstive. 

You'll gain valuable insight about what's good, what's wrong, and how you can start to create a more inclusive web experience, including a free audit downloadable report.