This content originally appeared on TPGi and was authored by James Edwards
This article is an overview of the new Success Criteria (SC) in WCAG 2.2 (Editor’s Draft). 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, five at Level AA, and two at Level AAA.
- 2.4.11 Focus Appearance (Level AA)
- 2.4.12 Focus Not Obscured (Minimum) (Level AA)
- 2.4.13 Focus Not Obscured (Enhanced) (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 Accessible Authentication (Level AA)
- 3.3.8 Accessible Authentication (No Exception) (Level AAA)
- 3.3.9 Redundant Entry (Level A)
SC 2.4.11 Focus Appearance
SC 2.4.11 is concerned with the visibility of focus indicators. 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 I know that some testers do interpret it this way and fail content against 1.4.11 for that reason). But the new SC 2.4.11 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.11 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.11 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 Success Criterion 2.4.11: Focus Appearance.
How to meet 2.4.11
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, using things like border and box-shadow, or outline-offset where supported:
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.11 also meets 2.4.7. Note that 2.4.7 itself has also been updated in WCAG 2.2: it’s been promoted to Level A (from Level AA).
SC 2.4.12 Focus Not Obscured (Minimum)
SC 2.4.12 requires that focused elements are not obscured by other content. 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 follow you and 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.
The understanding docs for this SC (Understanding Success Criterion 2.4.12: Focus Not Obscured (Minimum)) note that it 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.
This could be reasonably interpreted the other way 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.12
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. Sticky headers are a popular design choice, for some reason. So in that case, content will need to be carefully tested, by manually tabbing through the entire page, to ensure that no element is entirely obscured when it’s focused.
SC 2.4.13 Focus Not Obscured (Enhanced)
SC 2.4.13 is the same as 2.4.12 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.
Except that there is some ambiguity in the way this is worded. The normative requirement for 2.4.12 is that the component is not entirely hidden
, whereas the requirement for 2.4.13 is that no part of the focus indicator is hidden
. So theoretically, content could meet this SC if the focus indicator is entirely visible but the element it surrounds is hidden.
However the understanding docs (Understanding Success Criterion 2.4.13: Focus Not Obscured (Enhanced)) do refer to the element
or component
, not its focus indicator, so this may be regarded as a quirk in the wording: 2.4.13 is concerned with the whole element including its focus indicator, not just its focus indicator.
This could be a moot point anyway. Consider a button, for example, in which the text of the button serves as the visible label. If the button’s text is obscured, then this fails 3.3.2 Labels or Instructions, whether or not it fails 2.4.13.
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 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, 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.
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 target size to be less than 24×24 if the space between the targets is at least 24 pixels.
Frankly, I think the spacing exception is nonsense. It allows pointer targets of any size, even 0×0, as long as there’s 24 pixels of space between them. I find it hard to believe that that was the intention.
What I would infer from this (or should I say, what I think it should be), is that the target size + target spacing should add up to at least 48 pixels, with 24×24 as the minimum size of the target itself. So targets can be 24×24 and have 24 pixels of space between them, or they can be 36×36 with 12 pixels of space, or 48×48 with no space between them; but they cannot be smaller than 24×24 with any amount of spacing.
That is not what the SC says, but is what I would infer as a practical interpretation.
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 which are inline with text (such as text links within a paragraph) are also exempt from this SC. In the case of composite controls such as sliders, which have a small thumb within a larger slider track, the composite control itself is considered for the purposes of target size, i.e., the whole slider, not 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
In the absence of clarity on the requirements of this SC, I would suggest that the best way to meet it is to ensure that all applicable pointer targets have a minimum size of 24×24 pixels, and preferably, have at least 24 pixels of space between them; or if the controls are larger, they can have less space.
The pointer-target size is not necessarily the same as the visible target size. 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 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. 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.
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 anyway.
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 Accessible Authentication
SC 3.3.7 is concerned with cognitive function tests that are used to authenticate users, such as CAPTCHA tests where you have to type in a series of characters, or identify a specific kind of object in a gallery of similar images:
Such 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 exception to object recognition is where the cognitive test is based on content that the user has provided themselves. For example, if the user has already uploaded images to their account, then those images can be used for a required cognitive function test without failing this SC, since the user is expected to already recognize them.
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.7 (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.7
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.7.
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 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.7 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.8 Accessible Authentication (No Exception)
SC 3.3.8 is identical to 3.3.7, except that it has no exception for user-provided content.
SC 3.3.9 Redundant Entry
SC 3.3.9 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.9.
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.7 Accessible Authentication, it is not sufficient to meet 3.3.9.
How to meet 3.3.9
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.
The post New Success Criteria in WCAG 2.2 appeared first on TPGi.
This content originally appeared on TPGi and was authored by James Edwards
James Edwards | Sciencx (2022-08-19T11:21:01+00:00) New Success Criteria in WCAG 2.2. Retrieved from https://www.scien.cx/2022/08/19/new-success-criteria-in-wcag-2-2/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.