A thorough overview of the new success criteria added (and removed) in WCAG 2.2, including clear guidance on how to test and pass each one.
On what's changing:
There are nine new success criteria: two at Level A, four at Level AA, and three at Level AAA.
On the exceptions to obscured focus (for AA only):
If the obscuring content is semi-transparent, such that it does cover the element receiving focus, but it’s still possible to see that element because of the transparency, then this doesn’t fail 2.4.11
If users can move content regions, like draggable cards and toolbars, such that they obscure a focusable element, then the content doesn’t fail when the element receives focus, because the user caused that state.
The second is for content that’s been opened by the user, but which can be dismissed without moving focus. For example, a click-triggered top menu that’s intended to remain persistent until the user closes it, would not fail when an element underneath receives focus, if the user can close the menu without moving focus, such as by pressing ESC.
On how to best consider focus appearance to conform moving forward:
This new SC has additional requirements for the contrast between focused and unfocused states, and for the overall size of the focus indicator.
But the new SC 2.4.13 is specific about this: the difference between the focus indicator, and the same pixels 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.
If the focus indicator is an outline, then the contrast would be compared against the surrounding background
On how to calculate non-border-based focus states (hint: very tricky, just use a border):
If focus indicators are not enclosing borders or outlines, for example, a single solid-line inside the element, or a non-rectangular boundary defined by vector graphics, then the focus indicator will pass if its total area is equivalent to a 2px perimeter.
Dotted or dashed outlines can still be used, however since they only render half the area of a solid outline, the minimum width would have to be 4px.
On drop shadows and "glow" used in focus states:
Shadow and glow effects extending outside the outline (beyond 2px in this example) are not considered, and do not need to meet contrast requirements if the solid outline does.
On whether native browser indicators still pass (hint: nope/very unlikely):
Native focus indicators, provided by the browser, will only pass if neither the indicator nor the background has been author-modified.
On how to modify drag'n'drop to work with pointer-events:
Drag and drop scripting can be designed (or retrofitted) to also support point-and-click. The user could still grab an element and drag it from A to B as before, but they could also click the element at A, release the pointer, and then click the target B, to move the element from A to B. Alternatively, draggable widgets could include actionable menus, that specify where to move them.
On the logic behind exempting native elements from target size requirements, and how that applies to custom inputs:
SC 2.5.8 does not apply to elements that are solely defined by the browser, so things like native radio controls and checkboxes are exempted, if they have no author styling. However styled or custom radio controls and checkboxes are included, because they’re designed by the author not the browser.
On how you can use a person's avatar as a form of authentication control, but not text elements like their name:
Text-based personal content is not included in this exception, because that relies on recall rather than recognition.
On how blocking pasting into login forms is now an immediate failure:
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).
On how this may finally kill CAPTCHA:
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.
On how 2FA between devices is an insta-fail, as you cannot copy/paste but have to transcribe:
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.
On auto-masking password fields:
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.