WCAG 2.2 Success Criteria

Overview of WCAG 2.2

This blog is about overview of WCAG 2.2 and brief explanation of its Success Criteria (SC).

WCAG 2.2 extends WCAG 2.1 just like WCAG 2.1 extends WCAG 2.0. If you conform to WCAG 2.2, you also conform to both WCAG 2.1 and 2.0. There are 9 new Success Criteria introduced which we'll briefly cover in the following sections. Previously, 2.4.7 Focus Visible was changed from conformance Level AA to Level A but it remains at Level AA since no change took place. 4.1.1 Parsing is now obsolete and removed from WCAG 2.2. For in depth understanding, it's recommended to refer WCAG 2.2 documentation.

2.4.11 Focus Not Obscured (Minimum) (Level AA)

This SC talks about visibility of focused component. It states that while navigating in page using Tab key and Shift + Tab keys, the focused component (along with its focus indicator) should not get entirely obscured due to getting hidden, cut-off or overlapped by other content regions. It should be at least partially visible and it's only applicable when the component receives keyboard focus. This issue is commonly observed with content regions like sticky headers, sticky footers, and non-modal dialogs. Hence, it's recommended to avoid using sticky headers and sticky footers on your website. A properly constructed modal dialog will always pass this SC.

If the UI component is partially visible when light boxes or other semi-opaque effects overlap it, it may pass 2.4.11 Focus Not Obscured but we should evaluate & test whether color contrast ratio passes for the focus indicator or not (1.4.11 Non-text Contrast).

There are 2 notes associated with this SC.

Note 1: User-movable content
On a page load, if a content region obscures a focused component, then a mechanism should be provided for user to move/reposition that content region so that they can see the focused component. But this repositioning may obscure other components that may receive focus afterwards. Ensure that the movable content region in its initial position does not obscure the component receiving focus. Otherwise, it will be a failure of this SC. Examples include Toolbars in Authoring Tool, Draggable flashcards, Match the following activities etc.

Note 2: User-opened content
Contents opened by the user can obscure the pre-existing elements in the background that may receive focus. However, if user can bring the element with focus into view without actually altering or changing their current keyboard focus, then it doesn't fail this SC.
For example: A menu button opened/expanded by user may obscure the pre-existing components. If user can bring that pre-existing component into view by simply pressing Escape key to close expanded menu, then it's a pass.

2.4.12 Focus Not Obscured (Enhanced) (Level AAA)

This SC is related to the previous SC but it's more stricter of the two. The difference being that in this SC, the entire focused component (along with its focus indicator) should be fully visible with none of its part getting obscured. Whereas the previous SC fails only if the whole/entire focused component gets obscured.

2.4.13 Focus Appearance (Level AAA)

This SC talks about enclosure, thickness, minimum area of visibility, and color contrast for keyboard focus indicators.
Enclosure means how the focus indicator encloses the component whether by solidly bounding it or surrounding it (through closely and solidly following its shape/outline). Focus indicator can be outline, outline-offset, border or inset.

Area of focus indicators should be larger than the area of 1 CSS pixel perimeter (border/boundary outline excluding shared pixels) of the unfocused component. Hence, 2 CSS pixels solid thick outline can be thought of as minimum level of visibility for focus indicators. Also, it can be at least as large as 3 to 4 CSS pixels thick line along the shortest/smallest side of a minimum bounding box of the unfocused component.
Area of internal focus indicator like an inset will be lesser than the component perimeter area. However, increasing its thickness to at least 3 px will make its area larger and well above the minimum area requirements.

Remember that even 2 CSS pixels dashed/dotted focus indicators do not solidly enclose the component and its area will be lesser than the component perimeter area. To meet the area requirements, increase its thickness to at least 3 to 4 px or make custom focus indicators that solidly enclose the component.

If focus indicator encloses the component by bounding like outset (outline-offset) and outline, then color contrast (CC) ratio of focus indicator should be at least 3:1 against page background. If focus indicator encloses the component like a border outline, then CC ratio between focus indicator and border outline should be at least 3:1. If it's an inner outline like inset from within the component, then CC ratio should be at least 3:1 against component background. If the background color of component changes on receiving focus, CC ratio will be checked between original component background color and new background color when focused.

Difference between color contrast requirements in Focus Appearance & Non-text Contrast

Focus Appearance requires that focus indicators have a change of contrast between focused and non-focused states.
Non-text Contrast requires that focus indicators have adjacent contrast between the indicator (in the focused state) and adjacent non-indicator colors.

There's no need to test this SC if there's no focus indicator for a component as that will fail 2.4.7 Focus Visible.

Lastly, there are 2 exceptions to this SC:

1. The focus indicator is determined by the user agent and cannot be adjusted by the author, or
2. The focus indicator and the indicator's background color are not modified by the author.

2.5.7 Dragging Movements (Level AA)

This Success Criterion states that to perform a functionality that requires dragging movements, an alternative mechanism is available to perform the same task using a single pointer (single tap, single click, double tap, double click, long presses) where dragging movement is no longer needed.

Note that making the alternative mechanism as keyboard accessible only will not be sufficient to conform this SC. It's essential that the mechanism involves single pointer mode of operation to take care of other input devices other than keyboard-only.

Examples include slider, drag and drop for matching purpose, drag and drop for sorting purpose etc.

Difference with path-based gesture

Dragging movement is not a path-based gesture (direction-based and multi-point). In this, only the starting-point and end-point matter as it can go along any intermediary path in between these 2 points. There's no fixed intermediate path which user has to follow. In the path-based gestures, intermediate point matters where user has to go through this point which makes it a directional path-based gesture.

2.5.8 Target Size (Minimum) (Level AA)

The size of target region which accepts pointer input should be at least 24 by 24 CSS pixels. This helps to ensure that the desired target hit area is big enough to avoid accidental activation of adjacent targets. If you set component sizes to at least 24 by 24 CSS pixels with no spacing in between them, this SC passes. However, the target size can be less than 24 by 24 CSS pixels if it meets any of the following exceptions:

• Spacing: Imagine you drew a circle of 24 px diameter centered on the bounding box of component where all the points lie. The target region size can be smaller than 24 by 24 CSS pixels (i.e. undersized), provided, the circles do not intersect the adjacent targets or circles of other targets (of any size).
• Equivalent Target: A target does not need to have this minimum area requirement, provided, it has an equivalent target that has the same functionality which is of at least 24 by 24 CSS pixels.
• Inline: This Success Criterion does not apply to targets that are inline within blocks of texts like links within a sentence or paragraph. However, a stacked list of links that are not inline need to have minimum target region size requirements.
• User agent control: Default user agent controls used in the application are an exception to this SC if they are not modified by the author and used as-is.
• Essential: In few cases, target region size may go below 24 by 24 CSS pixels and there's no other way to change the size requirements if they are considered to be essential with no scope of changes. Because changing size requirements may change the meaning and functionality. So, this is an exception to this SC.

I would recommend not to restrict the target region size to 24 by 24 CSS pixels wherever possible. It's always suggested to go beyond compliance by increasing target region size to at least 44 by 44 CSS pixels which then conforms to 2.5.5 Target Size (Enhanced) Level AAA.

3.2.6 Consistent Help (Level A)

This SC requires that help mechanisms should appear in a consistent location in the same relative order if they are repeated within a set of web pages. This helps users to easily locate, identify and access them to seek help. It can either be provided directly or it can appear after activating an element which redirects user to help page. For instance, activating Contact Us link redirects user to Contact Us form page.

Help mechanisms can take any of the following forms:

• Human contact details like phone number, email ID, working days including operating hours.
• Human contact mechanism like messaging system, contact form etc.
• Self-help option like providing Frequently Asked Questions (FAQ) page where there's possibility of finding answers to the questions in user's mind. A tutorial page which shows step by step procedure on how to fill the application etc.
• A fully automated contact mechanism like an automated chat widget. If the chat bot fails to answer 2-3 rounds of questions/conversations, then connecting directly to support services person will benefit user.

Most commonly, these help methods are found in the Support Services section in the footer region of the applications.
Note that this SC does not require author to provide help mechanisms in the application. It applies only when any of the help mechanism is provided for users, and when repeated, those need to be consistently located, both visually and programmatically.

3.3.7 Redundant Entry (Level A)

This SC requires that if some information is entered by user in the previous steps, then the same information (if asked) can be entered again in the subsequent steps of that same process either by auto-populating the form fields or giving the user option to select them manually.
This benefits user by not having to recall what was entered in the previous steps; thereby avoiding giving out different and incorrect information. This may be encountered commonly in multi-step forms.

For example: In multi-step forms, you may have encountered a checkbox labeled "Shipping address is same as my billing address". Checking this checkbox automatically populates shipping address form fields with the values same as that entered in the billing address from the previous form step.

3.3.8 Accessible Authentication (Minimum) (Level AA)

This SC states that during the authentication process, cognitive function tests should be avoided. If it's used, then another alternative means should be made available to user so that they can easily log into the application without having to perform that cognitive function test.

Cognitive function test is a task that requires the user to memorize/remember, manipulate, or transcribe/write information.

The other alternate means of cognitive function tests that do not rely on it include the following:

• Mechanism: Enabling copy-paste feature so that user can easily copy and paste username, password. Giving user the provision to copy information from 3rd party password managers and pasting into the required form fields. Support for password entry by password managers to reduce memory need. However, blocking the copy-paste feature will fail this SC.
• Object Recognition: If a test involves remembering, transcribing words or recognizing a picture, then it would be a cognitive function test. The familiar objects or images that is recognized by the user is a cognitive function test, though, it is excepted at AA level. For instance, a CAPTCHA requires user to identify a particular object from the set of images. Though, it's best to avoid CAPTCHA when you can implement other methods.
• Personal Content: Identification of non-text content that the user themselves initially provided/selected during account registration. This identification of non-text content may serve as a 3rd step after filling username and password in the authentication process.

Offering a choice of device-based authentication methods to the user can allow them to choose the path that most suits them.

Using appropriate autocomplete attribute values for form fields that take personal information can help user in filling out information without the need for memorizing or transcribing.

The following methods are 2 Factor Authentication (2FA)/Multi-Factor Authentication (MFA) alternative means of cognitive function tests:

• One Time Password (OTP): Sending OTP to mobile device. Note that if it requires user to type in OTP into the browser application by referring/looking into the mobile device, then its a transcription task which fails this SC.
• Security Questions and Answers: User is required to enter answers to a few set of security questions. These are known to user and set by them during account registration step. It's still a barrier to the user as it involves recall and transcription.
• Push Notifications: After successfully entering the credentials and before logging user into the application, a push notification can be sent to user via email to alert them of their login and whether they want to proceed using "Yes, It's Me" or "No, It's Not Me" buttons.
• Biometrics: Fingerprint/ Password/ Facial Recognition to log into the application.
• Authenticator apps: The Authenticator app linked with the application generates 4 to 6 digits code to be entered to gain entry into app. Note that if it requires user to type in this code into the browser application by referring/looking into the mobile device, then its a transcription task which fails this SC.
• Populating OTP: Automatically populating OTP in the required form field by a simple tap which appears within the mobile app numeric keyboard helps to easily log into the app without having the user leave the app to open Messages app to type the OTP (transcribing task).

3.3.9 Accessible Authentication (Enhanced) (Level AAA)

This SC is the same as Accessible Authentication but without the exceptions for objects and user-provided content.