Skip to content
Home WCAG 2.2 – What to expect as per January 2023 Update!

WCAG 2.2 – What to expect as per January 2023 Update!

WCAG 2.2, January 2023 Update

The next version of Web Content Accessibility Guidelines (WCAG) 2.2 is scheduled to be published in April 2023 as per the new Candidate Recommendation released on January 25 2023. In the past, we have seen that the final release of WCAG 2.2 has been pushed back few times, June 2021, December 2022 and now the latest is April 2023. 

Back in August 2022, we had published a blog on WCAG 2.2 AQuick start Guide to find out what to expect from the new version of the guidelines. Since then two Candidate Recommendations of the guidelines have been released. The first one in September 2022 and the second one in January 2023. In this post, we will see what has changed from new success criteria’s, and removal of a success criteria to minor changes in the terms used in different success criteria’s.

The changes have been included at the start of each section of the below post for easy identification. In all there are 9 new success criteria’s being added in WCAG 2.2 as per the latest Candidate Recommendation. 1 success criteria, 4.1.1 Parsing is obsolete and has been removed from the guidelines. In addition, the conformance level for 2.4.7 Focus visible success criteria has changed from Level AA to Level A in WCAG 2.2. Out of these 9 success criteria’s: 

  • 2 are at Level A 
  • 5 are at Level AA 
  • 2 are at Level AAA 

Level A 

4.1.1 Parsing

The Parsing success criteria is obsolete and has been removed from WCAG 2.2 guidelines. This criteria is no longer useful because the accessibility errors that fail under this criteria are already covered by other success criteria’s. Additionally, modern browsers and assistive technologies can handle parsing errors and thus they are no longer creating accessibility errors for people with disabilities. WCAG 2.2 is backward compatible, i.e. it covers success criteria included in both WCAG 2.0 and 2.1. Even though 4.1.1 Parsing is removed from WCAG 2.2, it has not been removed from WCAG 2.0 and 2.1 as of now. In the future, this can happen for sure but for now in order to conform to WCAG 2.0 and 2.1 one needs to yet test for 4.1.1 Parsing at Level A. 

3.2.6 Consistent Help

The first “Note” of the success criteria has changed. As per the note, the help mechanism can be either provided on the page directly or a direct link can be provided to the page that contains the information.

The purpose of this success criteria is to ensure that users can find help consistently at the same location across different pages of the website or application. Finding help at a consistent location is beneficial for users with cognitive disabilities who would like to access help when they are not able to complete any task, such as filling up a form.

Help on a website can be in the form of: 

  • Contact information, email address, phone number, office timings
  • Contact form, messaging application, chat application, social media channel
  • Support page, FAQ page
  • Chatbot 

3.3.9 Redundant Entry

The purpose of this success criteria is to provide users with an option to either select previously filled details or auto-populate the details. This will avoid the need to enter the information again by users in a multi-step form and is found very helpful by users with cognitive impairments. This success criteria can be met by providing users to select previously filled information in the form of a drop-down and they can simply select the details. Alternatively, users can simply tick a checkbox, such as Nominee address is same as Applicant’s address or copy and paste the textual information in the respective input fields.

Exceptions include: 

  • Auto-populating the information will affect the security of the form.
  • It is essential to enter the information again as it is part of the activity, i.e. in the case of a memory game. 
  • Previously entered information is no longer valid.

Level AA 

2.4.11 Focus Appearance

The purpose of this success criteria is to ensure that the focus indicator for user interface controls is clearly visible and discernable. This will help users with mobility impairments and those with low vision who use a keyboard to easily locate their focus on the page.

The success criteria require that a visible focus indicator meets either one or both of the below-mentioned requirements: 

The entire focus indicator meets all the below requirements: 

  • Focus indicator encloses the user interface component or sub-component that is focused, i.e. solidly surrounds the control. 
  • Focus indicator should have a minimum contrast of 3:1 between its pixels and its focused and unfocused states. 
  • Focus indicator pixels should have a contrast of 3:1 with the adjacent non-focused indicator colors.
  • An area of the focus indicator meets all the below requirements: 
  • Area of the focus indicator is at least 1 CSS pixel thick of the unfocused component or sub-component, or is at least 4 CSS pixel thick line along the shortest side of the minimum bounding box of the unfocused component or sub-component. 
  • Area of the focus indicator should have a minimum contrast of 3:1 between its pixels and its focused and unfocused states. 

The area of the focus indicator pixels should have a contrast of 3:1 with the adjacent non-focused indicator colors or is not less than 2 CSS pixels. 

Exceptions include: 

  • Focus indicator is determined by the user agent, such as web browsers.
  • Focus indicator and its background is the default, i.e. generated by the browser and is not modified by the web page author. 

2.4.12 Focus Not Obscured (Minimum) 

The purpose of this success criteria is to make sure that when any user interface component receives focus, the component is not entirely hidden by any content created by the author. In order to meet this success criteria, some part of the component should be visible when it receives focus. For example, a non-modal dialog, sticky header/footer etc. can hide a focused component as well as its focus indicator. At any point, the user should be able to identify which component has focus currently on the page. This requirement is beneficial for people with low vision and those with mobility impairments.

2.5.7 Dragging Movements

The purpose of this success criteria is to help users carry out dragging functionalities through alternative means. People with dexterity impairments might find it difficult to carry out drag and drop activities or change values of a slider. Including an alternative method for functionalities based on dragging will help users accomplish their task easily.

A web page can provide users with drop-downs to select minimum and maximum price along with price range sliders in order to meet the success criteria. This success criteria does not apply to dragging movements that are part of user agents including assistive technologies and browsers. 

2.5.8 Target Size (Minimum)

In this success criteria, there are changes related to “Exceptions” for spacing and inline as well as “Note” for inline targets and line-height which are covered below. 

The purpose of this success criteria is to help users easily activate user interface controls and avoid unintentional activation of controls. When target sizes for controls are small users with mobility impairments who find to precisely control mouse movements will find it difficult to activate controls. Similarly, users browsing the web via mobile devices will also benefit by defining minimum target size of controls.

The minimum target size for pointer inputs is 24 by 24 CSS pixels. This requirement has the following exceptions:

  • Spacing: The target does not overlap with any other target and has a target offset of at least 24 CSS pixels with every adjacent target. 
  • Inline: The target is within a sentence or is in a bulleted or numbered list, or its size is otherwise constrained by the line-height of non-target text. 
  • Essential: It is essential to present a target with smaller size than the minimum recommended 24 CSS pixels. 
  • User Agent Control: Target size is determined by the user agent and not defined by the page author. 
  • Equivalent: An equivalent control exists on the page that meets the minimum target size requirements. 

In the case of inline targets, the line-heights should be interpreted as perpendicular to the flow of text. So for language that is displayed top – to – bottom, the line-height would be horizontal.

3.3.8 Accessible Authentication 

Before the release of the first Candidate Recommendation, this success criteria was at 3.3.7. The first “Note” of the success criteria has changed. As per the “Note”, "Object recognition" and "Personal content" may be represented by images, video, or audio. 

The purpose of this success criteria is to provide users with an accessible, easy to use and secure means to login and perform tasks. Users with cognitive disabilities who might not be able to memorize usernames or passwords rely on copy and paste functions and password managers to enter their credentials. If a website uses scripts that block password managers or copy and paste functions, then it becomes difficult for users to login into their accounts and perform different tasks.

The success criteria requires that authentications are easy to use, accessible and secured. Authentication should not require cognitive function and if they are based on cognitive function than an alternate method is made available.

Cognitive function that requires users to recognize objects or provide content to the website is considered as an exception to the success criteria.

Talk to our Accessibility Expert

Level AAA 

2.4.13 Focus Not Obscured(Enhanced)

Before the release of the first Candidate Recommendation of WCAG 2.2 this success criteria was named as 2.4.12 Focus Appearance (Enhanced).

The purpose of this success criteria is to make sure that when any user interface component receives focus, the component is fully visible and is not hidden by any content created by the author. This success criteria is similar to 2.4.12 Focus Not Obscured (Minimum) and the only difference is that it requires that the focus be fully visible whereas as per 2.4.12, it is acceptable even if only some part of the focus is visible. 

3.3.9 Accessible Authentication (Enhanced)

As per the first Candidate Recommendation of WCAG 2.2 this success criteria was named as Accessible Authentication (No Exception). The criteria has now been renamed to Accessible Authentication (Enhanced). 

The purpose of this success criteria is to provide users with an accessible, easy to use and secure means to login and perform tasks. Users with cognitive disabilities who might not be able to memorize usernames or passwords rely on copy and paste functions and password managers to enter their credentials. If a website uses scripts that block password managers or copy and paste functions, then it becomes difficult for users to login into their accounts and perform different tasks.

The success criteria requires that authentications are easy to use, accessible and secured. Authentication should not require cognitive function and if they are based on cognitive function than an alternate method is made available. This success criteria is similar to 3.3.8 Accessible Authentication but does not include exceptions related to objects and user-provided content.

Would be great to see what the finally published WCAG 2.2 Guidelines looks like. The number of success criteria for meeting conformance will increase by 9 and take the total to 86 at Level AAA and 56 at Level AA if none of the above is removed! 

We would be happy to assist you with any questions or information you need related to WCAG 2.2 or accessibility. Get in touch with our accessibility consultant at sales@barrierbreak.com.

Leave a Reply

Your email address will not be published. Required fields are marked *

Back To Top