With version 2.2 due for release in early 2023, we've looked at what to expect from the new criteria, any changes from version 2.1, and how you can get ahead of the curve and start thinking about these changes now during product development.
What is WCAG?
WCAG provides a set of specific criteria, organised according to principles, guidelines and success criteria, used to measure and improve the accessibility of web content. It sets the standard for how websites and other digital content should be made accessible and user-friendly for everyone, regardless of their disability or impairment.
WCAG has announced a new and improved list of success criteria - WCAG 2.2, due in the coming months. These updates will help improve the following areas:
The use of a keyboard
Avoiding reliance on dragging movements
Ensuring controls are sufficiently spaced out
Displaying help mechanisms consistently across websites
Letting users authenticate without cognitive tests
Avoid asking for repeated information
Before diving into the details, it's important to note WCAG grades its criteria with certain levels of conformance:
A (Single A)
The minimum level of requirement all websites, apps, and digital content such as documents should follow.
AA (Double A)
Includes all A and AA requirements and is the conformance level many businesses strive for. This is a hard requirement for .GOV services.
AAA (Triple A)
AAA compliance is the highest standard level of accessibility and includes all A, AA and AAA requirements, which provides everything for a completely accessible offering and makes up the difference between a good experience and an excellent one. It's generally not considered a good idea to adopt this as a general policy as some content cannot reach this level of conformance, but there is no harm in aiming for this level in some success criteria.
What criteria can you expect?
Focus: A better experience for keyboard navigation
The requirement level for focus visibility and appearance has become more strict; here's what to expect: 
Focus visible (A):This criteria has been promoted from level AA to A, requiring interactive elements that can receive keyboard focus to have that focus be visible.This is great, as it means that it will be a minimum requirement to ensure that people that rely on keyboard navigation to know where they are on a page.
Focus appearance (AA): Visible focus states for keyboards need to be clearer and meet AA standards. This criteria revolves around focus states having more contrast between their unfocused states and any background elements.
Focus not obscured (AA/AAA): We've all probably seen sticky elements on a site for example cookie banners, sticky navigation/headers. Whilst they can be a useful user experience feature they can create issues for people navigating via keyboard. The issue arises when the focus state of an element is blocked by user generated content that is sticky.
These new success criteria aim to deal with focus states being full blocked (AA) or partially blocked (AAA). As with the previous two criteria, this is another aimed at helping make sure focus states are always clearly visible to people who rely on them to navigate a page.
Filling out forms/repeated information
Filling in forms can be a stressful experience for users with accessibility needs; here's what to expect:
Redundant Entry (A): Filling out large or complex forms can be a frustrating task for anybody and even more cumbersome when using assistive technology. This criteria aims to make using data already known by giving the option to fill in multiple forms at once.
There are some caveats here in that any data that needs to be manually input essentially, or is considered private, secure information should not always be saved and reused. For example reentering a password to confirm its use.
Note: Allowing for autofill should be considered when thinking about form input states. For example could it potentially block any validation showing relating to the field?
Accessible authentication (AA/AAA): Cognitive function tests, such as solving puzzles and remembering passwords, are not accessible. To achieve AA status there needs to be a way for someone to authenticate who they are without needing to take cognitive function tests.
To meet AA conformance there are some exceptions to this criteria: there is a mechanism to assist the person in completing the function test; the test is to recognise objects; or the test involves data that the person has entered themselves. For the AAA (enhanced) version of this criteria, only the first two of those exceptions are allowed.
Think about offering different ways for people to authenticate, for example facial recognition, getting a code text, fingerprint, and allowing the use of a password manager.. The more options, the more somebody is likely to find something that works for them.
Predictability
Creating accessible journeys is vital to making websites user-friendly; here's what to expect:
Consistent help (A): If something can go wrong, it will. People should be able to find help quickly and consistently throughout their entire journey. This includes ensuring support contact details are in the same place on each page and aren't moving around or changing. Having that reassurance of where to consistently find help if needed could massively reduce stress during a journey.
Input assistance
Dragging movements (AA): Not everybody has the ability to perform dragging actions like dragging an element using a mouse to reorder it. If functionality relies on this action it can create barriers for people accessing important information or completing tasks.
Single pointer event alternatives should be provided to meet this criteria. For example, having to drag to navigate around a map, there should be a button that can be clicked/tapped to move the view also. 
Target size (AA): Ensure that the size of any interactive elements such as buttons (particularly think icon buttons) is at least 24x24px. This criteria aims to prevent small controls being too close to each other and making it hard for people to interact with. This can help people who suffer from loss of dexterity, such as hand-eye coordination issues. It will be particularly helpful for mobile devices, and consider situational accessibility here as well.
Note: This criteria does not include online controls such as links in a block of text. You may have heard some designers mention 44x44px being the ideal tap target and this is a great rule to follow. There is already a AAA guideline that suggests this sizing. This new criteria introduces a minimum requirement.
How do you implement it?
These new guidelines are expected to take time to implement, but there's absolutely no harm in getting ahead of the curve.
For example, the GOV.UK accessibility strategy published recently, outlines their plans to implement WCAG 2.2 conformance, this states:
After WCAG 2.2 is formally published, they aim to align with the new recommendation by:
releasing updates through GOV.UK Frontend for styles, components and patterns during the first 6 months
updating the GOV.UK Design System website during the first 9 months
building new components and patterns that help teams meet WCAG 2.2 during 2023
They will then be checking their services against WCAG 2.2 criteria from 2024. This is one organisation's strategy and isn't a hard deadline to follow, but it does show that implementing these new guidelines on large projects with many complements in a design system will no doubt be more work.
However, the earlier these criteria can be considered during the design and build of products, the easier they are to implement. Flagging any necessary changes early will help drive accessibility more effectively. This could be both internally at a design stage, or in tickets regarding already built components. It's also worth exploring how any third-party services your site may rely on to implement these guidelines if you're planning on updating to this conformance level.
. . .
Want to learn more? Accessibility needs all of us, and a great way to participate is by continuously learning and sharing your knowledge.
