This article is an overview of the new Success Criteria (SC) in WCAG 2.2. We’ll be looking at each of the new SCs in turn, describing their requirements in plain language, and discussing how to meet them.
WCAG 2.2 is a fairly small update compared with WCAG 2.1. There are nine new success criteria: two at Level A, four at Level AA, and three at Level AAA.
- 2.4.11 Focus Not Obscured (Minimum) (Level AA)
- 2.4.12 Focus Not Obscured (Enhanced) (Level AAA)
- 2.4.13 Focus Appearance (Level AAA)
- 2.5.7 Dragging Movements (Level AA)
- 2.5.8 Target Size (Minimum) (Level AA)
- 3.2.6 Consistent Help (Level A)
- 3.3.7 Redundant Entry (Level A)
- 3.3.8 Accessible Authentication (Minimum) (Level AA)
- 3.3.9 Accessible Authentication (Enhanced) (Level AAA)
In addition to the new ones, SC 4.1.1 Parsing has been marked as obsolete and removed. This SC was originally intended to address problems that assistive technologies might have in parsing HTML directly. However these technologies no longer have any need to parse HTML directly, therefore this SC is no longer useful. Any failures of this SC that have an actual user impact are already covered by other SCs, and Adrian Roselli’s article The 411 on 4.1.1 has a lot of useful guidance here.
It had previously been planned that 2.4.7 Focus Visible would be promoted to Level A (from Level AA), but this change has now been reverted and isn’t going to happen.
SC 2.4.11 Focus Not Obscured (Minimum)
SC 2.4.11 requires that focused elements are not obscured by author-created content (browser-native or system content is excepted). It only applies to elements when they’re actually focused, not just to any element that might become focused. This benefits all keyboard users, particularly some users with cognitive or memory impairments, by ensuring that it’s easy to identify where the focus position is.
This issue can most commonly occur with things like sticky headers and non-modal dialogs. For example, if you have a page with a sticky header, and tabbing through the page causes the sticky header to entirely obscure an element when it’s focused, then it fails this SC. Partially obscuring an element (e.g., covering half of it) does not fail.
This doesn’t include situations where the user themselves can move content to obscure a focused element. For example, if a non-modal dialog is draggable and can be moved by the user to cover an element that’s focused, then it doesn’t fail; only the initial state is considered. That could be reasonably interpreted the other way round as well: that if the user can move content to reveal an obscured element (such as using Arrow keys to scroll the sticky header away), then it still fails, because that is not the initial focused state.
How to meet 2.4.11
The easiest way to meet this SC is not to have any kind of sticky or floating content at all. (This also intersects with 1.4.4 Resize text and 1.4.10 Reflow, if increases in page zoom cause focusable elements, or any other content, to become obscured.)
However that may not be realistic, while sticky headers are a popular design choice. So in that case, content will need to be carefully tested, by manually tabbing forwards and backwards through the page, to ensure that no element is entirely obscured when it’s focused.
SC 2.4.12 Focus Not Obscured (Enhanced)
SC 2.4.12 is the same as 2.4.11 except it’s less forgiving. Whereas the previous SC is only failed if the focused element is entirely obscured, this SC fails if any part of the focused element is obscured by author-created content.
SC 2.4.13 Focus Appearance
SC 2.4.13 is concerned with the visibility of author-created focus indicators (browser-native focus indicators are excepted). It covers aspects of two existing SCs: 2.4.7 Focus Visible (which requires that focus indication must be visible) and 1.4.11 Non-Text Contrast (which, among other things, requires that focus indication has a minimum 3:1 contrast against its background).
However this new SC also has additional requirements for the contrast between focused and unfocused states, and potentially, for the shape or thickness of the focus indicator as well. So it goes beyond those earlier SCs by requiring not just visibility, but a minimum level of visibility. This benefits all keyboard users, but particularly benefits low-vision keyboard users.
The existing SC 1.4.11 requires focus indicators to have minimum contrast, but does not explicitly require the difference between focused and unfocused states to also have minimum contrast. (Although some testers do interpret it that way, and fail content for that reason, it isn’t actually a technical failure of 1.4.11.) But the new SC 2.4.13 is specific about this: the difference between the focus indicator, and the same pixels that it would take up when the focus indicator is not shown, must have a minimum 3:1 contrast. This is because a low-contrast change in state will be difficult for some users to discern; if an element’s focus state is visually very similar to its unfocused state, then they might not perceive the difference.
So for example, if a button has a white border that changes to blue when it has focus, then the difference between the white and blue colors must be a minimum of 3:1, as well as the blue color having 3:1 contrast against its background. If the blue border directly touches the button, then it must also have 3:1 contrast against the button background.
Finally, 2.4.13 requires that the focus indicator itself either solidly encloses the element, or is sufficiently thick as to be visible enough without solidly enclosing it. Note the emphasis on solidly: a 1px dotted or dashed outline does not solidly enclose the element (because it’s not solid), and therefore does not meet this requirement.
However 2.4.13 also allows for a second way of conforming when the focus indicator does not solidly enclose the element; essentially, by making it thicker. This allows for things like dashed outlines, single solid lines (e.g. underneath or inside the element), or non-rectangular element boundaries, to be used as focus indicators. These can conform to the SC if they occupy enough space relative to the size of the element. The calculations for this can get quite complicated, so for more details it’s best to read the understanding docs: Understanding SC 2.4.13: Focus Appearance.
How to meet 2.4.13
The simplest way to meet this SC is to use solid outlines for focus indication. An outline style of 1px solid is sufficient for conformance, but I recommend 2px solid to make it even clearer.
A focus outline is visible when the element is focused, and not present at all when it isn’t, so here the contrast ratio between those two states is the same as the contrast ratio between the outline and its background. If the outline is also rendered so that it doesn’t touch the element, then its contrast doesn’t need to be compared with the element, only with the background. This can be done in several ways, but the simplest approach is to use outline-offset:
If focus outlines are designed in this way, then there’s only one applicable contrast ratio to consider: the outline against its background. And since a solid outline usually encloses the whole element, all requirements would be satisfied.
If this criterion is met, there’s no need to separately test 2.4.7 Focus Visible; meeting 2.4.13 also meets 2.4.7.
SC 2.5.7 Dragging Movements
SC 2.5.7 deals with interfaces that use pointer dragging movements, such as drag and drop, or drag sorting. It requires that any interface which has this functionality can also be operated by a single pointer without dragging movements.
The current SC 2.5.1 Pointer Gestures does not apply to drag and drop, because it isn’t a multipoint or path-based gesture. With drag and drop, you grab an element at one location (Point A) and then drop it somewhere else (Point B), but the path your pointer takes to get from A to B is not significant, only the end point matters, therefore it’s not a path-based interaction.
This new SC 2.5.7 is specifically for the case of dragging movements, where the whole motion may be difficult for some pointer users to perform. Even the simplest dragging motion requires quite precise pointer control, which may not be possible for users who have issues with fine motor control, or who use assistive technology that simulates pointer movement from voice commands or other input.
How to meet 2.5.7
Drag and drop scripting can easily be retrofitted to support point-and-click. So a user could grab an element and drag it from A to B as before, or they could click the element at A, release the pointer, and then click the target B, to move the element from A to B. That’s all it takes.
Graphical color-pickers generally already pass this requirement. You can drag the pointer around inside a multi-colored region to inspect and select different colors, which is a dragging movement, but you can also single-click discreet points to select the color at that point. Therefore 2.5.7 is already satisfied.
Note that keyboard accessibility is not sufficient to meet this SC. Any drag and drop interface should be keyboard accessible (or an alternative interface provided which is), but that in itself is not sufficient to meet 2.5.7; this SC is only concerned with pointer interaction.
SC 2.5.8 Target Size (Minimum)
SC 2.5.8 is a downgraded version of the current SC 2.5.5 Target Size (which is Level AAA), relaxing the size requirements and making it a AA checkpoint. Whereas 2.5.5 requires most interactive elements to have a minimum pointer-target size of 44×44 CSS pixels, this new SC 2.5.8 only requires a target size of 24×24 pixels. But it also includes an exception for target spacing, which allows the targets to be less than 24×24, if they’re far enough away from each other.
This exception is described in terms of overlapping circles. For each target element that is smaller than 24×24, imagine that you drew a circle with a 24 pixel diameter (12 pixel radius), that is centered over the target. If none of those circles overlap each other, or any other target, then the spacing exception is passed.
SC 2.5.8 does not apply to elements that are rendered by the browser, so things like native radio controls and checkboxes are exempted. However custom radio controls and checkboxes are included, because they’re designed by the author not the browser. Interactive elements that are inline with text are also exempt from this SC, so this include text links within a sentence, or anywhere else that the size of the target is constrained by the line-height of non-target text. In the case of composite controls such as sliders, which have a small thumb within a larger track, the composite control itself is considered for the purposes of target size, i.e., the whole slider, not just the thumb inside it.
Page zoom is not a factor in target size. CSS pixels do not change with zoom level, so an element that’s 16×16 at 100% zoom, is still 16×16 at 400% zoom. There’s no loophole for controls that could be larger if the user zooms.
How to meet 2.5.8
The simplest way to meet this SC is to ensure that all applicable pointer targets have a minimum size of 24×24 pixels.
The pointer-target size is not necessarily the same as the visible target size. For example, a graphical button with a visible icon that’s 16×16, but has 4px padding on every side, adds up to a pointer-target of 24×24.
However 24×24 is still quite small, and could still be difficult for some users who have issues with fine motor control. So the best advice I can give is to ignore this SC entirely and follow the requirements of 2.5.5 Target Size instead (minimum 44×44).
Meeting 2.5.5 will also meet 2.5.8.
SC 3.2.6 Consistent Help
SC 3.2.6 is about the consistent placement of information that provides general help to users, specifically points of human contact. So this would be things like a telephone number or email address, at which users can get help with the site, or with the company’s service in general. This SC does not require that such things be provided, only that if they are provided, they can be found in a consistent location. This is helpful for all users, but may be particularly beneficial for some users with cognitive or memory impairments.
So for example, if you provide a help-line for users, and the phone number for this help-line is in the header, then it should always be in the same place in the header, on every page where it appears. In these terms, same place
refers to its source position as well as its visual position, i.e. the same place within a serialized representation of the page. This only applies when it’s repeated on multiple pages; if it only appears on one page then 3.2.6 doesn’t apply.
Note that 3.2.6 is not concerned with contextual help, such as notes or tooltips underneath a form field that give help for completing the field. That kind of contextual help is already covered by the existing SC 3.3.5 Help (I Need Somebody).
How to meet 3.2.6
Meeting this SC comes down to consistent design and templating. If you provide this kind of help or contact information on multiple pages, then make sure it’s always in the same place. Chances are, you’re already doing that.
Whether this help amounts to direct information (such as a phone number), or is a link to another page on which that information can be found, is not significant; the requirements of 3.2.6 apply to the information or link as it’s presented.
The wording of this SC is also slightly ambiguous. The name of the SC refers to help
but the normative requirements mostly refer to contact
information. In plain language, contact does not imply help. But 3.2.6 is specifically concerned with points of human contact that are channels for getting help. So something like a company’s corporate address, in the footer, would not be covered, if it’s not explicitly intended to be a means of getting help.
SC 3.3.7 Redundant Entry
SC 3.3.7 is about preventing users from having to re-enter information they’ve already entered before (within the same session), to reduce cognitive load. This may be beneficial for users with cognitive or memory impairments, and also for users with mobility impairments who rely on voice-recognition or switch controls, for whom data entry can be extremely laborious.
So for example, a multi-page application form might ask for the user’s name and address in more than one place. When it does this, the information they’ve already entered must either be pre-populated in the form, or available for them to select from. The exceptions to this are where it’s essential that they re-enter the information (such as entering a new password twice to verify that they’re the same), or where the previous information is no longer valid.
This SC does not apply in cases where the previously-entered information was in a different format. For example, if an online application requires the user to upload their Resume in a document format, and also requires them to enter their employment history in a web form, then this is not covered by 3.3.7.
However it does still apply in cases where the user can populate fields using their browser’s auto-complete, or similar tools. Although that would be sufficient to meet 3.3.8 Accessible Authentication (Minimum), it is not sufficient to meet 3.3.7.
How to meet 3.3.7
It’s fairly simple to implement the session logic for pre-populating fields using information the user has already entered. Alternatively, providing for users to select prior information could be implemented as a <select> element, it could be a checkbox for something like “Use my billing address as the shipping address”, or it could just be text on the page that the user can copy-paste from.
SC 3.3.8 Accessible Authentication (Minimum)
SC 3.3.8 is concerned with cognitive function tests that are used to authenticate users, such as solving a puzzle, or remembering a password.
CAPTCHA tests that ask you to identify an obfuscated word are included in this SC. However tests that ask you to identify a familiar object are specifically excepted:
Even though this is a cognitive function test, it’s listed as an exception because the objects are generally familiar to users. Being able to recognize, say, a street light or a car, is considered sufficiently easy. There is still the potential for cultural lack of familiarity; the images in these tests are generally US urban scenes, which include objects you may have never seen before, or don’t know what they’re called. But this is not an accessibility issue, so it’s not considered as part of WCAG.
Note that the “object” in object recognition tests is not limited to images, it also includes video or audio content.
A further exception is for non-text content that the user themselves has provided to the site. For example, images from the user’s own profile can be used for a cognitive function test, even if they wouldn’t otherwise be considered to be objects, and a possible application would be a set of images that asks you to recognize yourself. Text-based personal content is not included in this exception, because that relies on recall rather than recognition.
Cognitive function tests may be difficult or impossible for some users to complete, for example, if they have cognitive issues with memory, reading, numeracy, or perceptual processing. This SC requires that if such tests are used, then either an alternative is available that does not rely on a cognitive function test, or a mechanism is available to help users complete it.
The definition of “cognitive function test” includes anything that requires the user to remember and transcribe information, and this includes username and password authentication. However if the site allows for password managers to be used, then that’s a mechanism which helps users to complete it. That kind of input would only fail if the site is explicitly blocking support for those tools, and the most likely cause of that would be preventing copy-pasting into username and password fields. Some sites do this for ‘security reasons’, but that is now an explicit failure of SC 3.3.8 (for which no exception is allowed on the basis of security, because there aren’t actually any security issues with copy-pasting into username and password fields).
The specific exceptions to this are fields that request the user’s name, email address, or phone number; those things are personal information that doesn’t change between different sites, and therefore inputting them is not considered a cognitive function test.
How to meet 3.3.8
The first way to meet this SC is to ensure that all forms of authentication input (such as username and password fields) support copy-pasting their values. It’s also a good idea to include an autocomplete attribute on all fields that ask for a user’s own information (as described in the existing SC 1.3.5 Identify Input Purpose), even though this is not strictly required by 3.3.8.
Over and above that, it’s best to avoid using CAPTCHA or similar gatekeeping tools, which can never be fully accessible. But if you do use those things, then ensure that other forms of authentication are available; 2-Factor Authentication (2FA) is usually a good option.
Note however that the 2FA itself must also meet the same requirements. For example, if the 2FA sends a code to the user, that then requires them to type that code into their browser, this would fail 3.3.8 unless they can directly copy-paste from one to the other (because otherwise it’s a requirement to transcribe information). So if the 2FA required a separate device, like a code sent to the user’s cellphone which must be entered into a desktop browser, then that would fail this SC. Requiring the user to input only certain characters of an authentication string (such as, entering the 1st, 3rd, and 6th digit of a passcode) would also fail, even if copy-pasting is possible, because the input is required in a format that is different from the original passcode.
Something simpler, like a temporary URL where the user can just click a link in an email or text message to validate themselves, would be fine. The use of biometric authentication, such as fingerprint scanning or facial recognition, also meets this SC.
Hiding authentication information as it’s entered does not fail this SC, for example, using a type="password" field which obscures the input characters. However it is still a good idea to include “show password” functionality.
SC 3.3.9 Accessible Authentication (Enhanced)
SC 3.3.9 is identical to 3.3.8, except that it has no exceptions for object recognition tests or personal content.
