WCAG 2.2 has finally been released. How does this affect you?

The web is a place that all people should be able to access, no matter their social status or physical impairments. 

Web Content Accessibility Guidelines (WCAG) define how web content can be made more accessible to people with disabilities. These guidelines are drawn up by the World Wide Web Consortium (W3C), an international community that was set up to ensure the long-term growth of the web through the development of standards. 

Physical barriers to using the web include: 

• mental or physical impairments such as working with a broken arm or being colour blind 
• situational impairments, such as working with a broken arm or in a noisy environment 
• technological impairments such as using outdated equipment or being in an area with a poor internet connection. 

But if websites are coded and designed properly these impediments shouldn’t stop users from being able to access the information they need. 

The aim of the guidelines is to provide a shared accessibility standard that meets the needs of individuals, organisations, and governments internationally. They have been developed in cooperation with individuals and organisations around the world. 

We have written previously about why it is important for websites to include as many people as possible. We have also detailed how it can boost a business’s bottom line. 

The first set of accessibility guidelines was published in 1999, and things have certainly changed in the past 24 years! The latest edition, WCAG 2.2, finally became the W3C Recommendation on 5 October 2023. 

In this blog we look at the latest version of the guidelines, which have been updated to improve guidance for disability groups and reflect changes in technology and the web. 

This is what you need to know

After much toing and froing, WCAG 2.2 is now the W3C Recommendation – a more forgiving version than the working draft, which would have introduced more level A guidelines. 

Those guidelines pertaining to Focus Appearance and Visible Controls were reworked and moved to level AAA due to their complexity. 

4.1.1 Parsing (A) has been marked obsolete and removed

Originally to address problems that assistive technology had directly parsing HTML, however with browser improvements and the Accessibility API this is no longer relevant or issues covered by other criteria. 

These are the official, latest success criteria introduced in WCAG 2.2: 

2.4.11 Focus Not Obscured (Minimum) (AA) 

When a user interface component receives keyboard focus, the component is not entirely hidden due to author-created content. Particularly relevant where "sticky" elements on the page might obscure the current focus, this criteria requires that the focused component be at least partially visible. 

2.4.12 Focus Not Obscured (Enhanced) (AAA) 

The stricter version of 2.4.12, requires that the focused component be entirely visible without any user action .

2.4.13 Focus Appearance (AAA) 

When the keyboard focus indicator is visible, an area of the focus indicator meets all the following: 

• is at least as large as the area of a 2 CSS pixel thick perimeter of the unfocused component or sub-component, and 
• has a contrast ratio of at least 3:1 between the same pixels in the focused and unfocused states 

Originally 2.4.12 & 2.4.13 were part of a single criterion 2.4.11 Focus Appearance (Minimum) (AA), but due to the complexity they were split out and moved to level AAA, and 2.4.11 introduced for level AA. 

2.5.7 Dragging Movements (AA) 

Unless dragging is essential, a single pointer should be used instead of a functionality that uses a dragging movement for operation. This requirement applies to web content that interprets pointer actions (i.e. this does not apply to actions that are required to operate the user agent or assistive technology). 

2.5.8 Target Size (Minimum) (AA) 

Targets for pointer inputs (mouse, touch) should have an area of at least 24 by 24 CSS pixels, except where the target offset is at least 24 CSS pixels to every adjacent target or the target is in a sentence or block of text or a particular presentation of the target is essential to the information being conveyed. 

Little brother of 2.5.5 Target Size (Enhanced) (AAA) which requires 48 by 48 pixels. 

3.2.6 Consistent Help (A) 

If a web page provides a way of finding help, then access to at least one of these must also be included: 

• Human contact details 
• Human contact mechanism 
• Self-help option 
• A fully automated contact mechanism. 

3.3.7 Redundant Entry (A) 

This involves information previously entered by or provided to the user that is required to be entered again in the same process and in the same user-session. This information should either be auto-populated, or available for the user to select, except when: 

• Re-entering the information is essential 
• The information is required to ensure the security of the content 
• Previously entered information is no longer valid. 

3.3.8 Accessible Authentication (Minimum) (AA) 

Authentication has become a popular way to secure accounts. If you're not trying to verify your identity with an app, you’re trying to answer questions, remember passwords or click on all of a certain item in a set of pictures. 

But not all of these authentication methods are accessible. 

This new guidelines states that a cognitive function test (such as remembering a password or solving a puzzle) is not required for any step in an authentication process unless that step provides at least one of the following: 

• Alternative: Another authentication method that does not rely on a cognitive function test. 
• Mechanism: A mechanism is available to assist the user in completing the cognitive function test. 
• Object Recognition: The cognitive function test is to recognise objects. 
• Personal Content: The cognitive function test is to identify non-text content the user provided to the website. 

3.3.9 Accessible Authentication (Enhanced) (AAA) 

This is the stricter version of 3.3.8, where Object Recognition and Personal Content are not accepted as alternatives for cognitive fun tests.

What do these changes mean for you? 

At the moment, EU regulations (EN 301 549 V2) state that websites and mobile apps of public sector bodies should meet all Level AA Success Criteria to be compliant with WCAG 2.1. 

But with the introduction of these new guidelines, and with the European Accessibility Act coming into play in June 2025, EU regulations will change, and forward-thinking organisations would probably like to get a jumpstart on the tweaks they will eventually make to their websites. 

Getting a jump on the changes means that things can be done at a pace that you are comfortable with, and also eliminates a mad dash to a regulation-stipulated deadline.

Next steps 

The best way to kickstart your WCAG 2.2 compliance journey is to know what changes you need to make. The best way to do this is to have an accessibility audit done of your website. 

An audit will identify any issues that may be prohibiting people from using your site properly – especially those users who may be relying on assistive technologies such as screen readers, magnifiers or input devices. 

Annertech has considerable experience conducting website accessibility audits and evaluating them against each of the different WCAG criteria. With each audit we also provide practical recommendations to resolve any issues found. 

Once the recommendations have been implemented it will not only ensure that the website will meet all the success criteria for WCAG 2.2 but that all users will have an improved user experience, no matter any physical challenges they may have. 

We recommend that an accessibility audit be conducted as soon as possible to ensure any remediation required is completed in advance of EU regulation changes.