Posted on by Patrick H. Lauke in Standards
This post gives a high-level overview of what's new and what has changed in the Web Content Accessibility Guidelines (WCAG) 2.2, which have been promoted to stable W3C Recommendation today.
WCAG updates are intended to be backwards-compatible – by satisfying the requirements of WCAG 2.2, your site also satisfies the requirements of earlier versions of the specification. For this reason, the majority of WCAG 2.2 remains unchanged from WCAG 2.1.
One "breaking" change from WCAG 2.1 is the removal of Success Criterion 4.1.1 Parsing.
This criterion was useful when it was first introduced in WCAG 2.0 back in 2008, but thanks to changes in the HTML standard that specify a consistent way for browsers to error-correct malformed markup, it no longer provides any benefit to people with disabilities. Any other issues related to invalid markup that impact users – in particular, people who use screen readers/assistive technologies – are still covered in more specific Success Criteria, such as 1.3.1 Info and Relationships and 4.1.2 Name, Role, Value.
While 4.1.1 Parsing is still in WCAG 2.1, the latest re-published version of the standard (which should coincide with the release of 2.2) will contain an advisory note for 4.1.1 Parsing, stating that the criterion should always be considered satisfied (for HTML and XML content), effectively deprecating the requirement.
Beyond this change, WCAG 2.2 introduces 9 new Success Criteria:
When a user interface component receives keyboard focus, the component is not entirely hidden due to author-created content.
Sighted people who can't use a mouse need to see what has keyboard focus. Some web pages include content that is designed to "stick" to a specific area of the page, even when the page is scrolled, or otherwise overlap existing content. This includes sticky headers/footers, cookie banners, and floating sidebars and menus. This can lead to keyboard focus disappearing behind these elements, which is problematic.
Ensure that when an item gets keyboard focus, the focus is at least partially visible. Depending on the type of content, there are different techniques using CSS that can help mitigate problems as discussed in our post Sticky content: focus in view. As a best practice, avoid overlapping content altogether.
For configurable interfaces, where a user can open and then move content, the criterion only applies to the initial position of the content. Similarly, if a user can open additional content and then reveal the focused element without needing to move focus, the criterion is satisfied.
For more information see Understanding SC 2.4.11: Focus Not Obscured (Minimum) (Level AA).
When a user interface component receives keyboard focus, no part of the component is hidden by author-created content.
This success criterion is similar to its AA counterpart, except that the entirety of the focus indicator must be unobscured, and there are no exceptions for configurable interfaces or the user's ability to make focus visible again after opening additional content.
For more information see Understanding SC 2.4.12: Focus Not Obscured (Enhanced) (Level AAA).
When the keyboard focus indicator is visible, an area of the focus indicator meets all the following:
- is at least as large as the area of a 2 CSS pixel thick perimeter of the unfocused component or sub-component, and
- has a contrast ratio of at least 3:1 between the same pixels in the focused and unfocused states.
Exceptions:
- The focus indicator is determined by the user agent and cannot be adjusted by the author, or
- The focus indicator and the indicator's background color are not modified by the author.
Since WCAG 2.0 we have had success criterion 2.4.7 Focus Visible, which requires a visible indicator for elements that have keyboard focus. However, WCAG never normatively defined what "visible" meant in practice. While 1.4.11 Non-text Contrast in WCAG 2.1 defines the minimum contrast ratio for a focus indicator, it still doesn't cover its minimum dimensions and appearance. This criterion more specifically defines what a visible indicator must look like – both in terms of size/overall area, and what the difference in contrast must be between an element's focused and unfocused state.
Originally, this criterion was going to be at AA, but due to its complexity it was moved to AAA. This means that for sites that only work towards A/AA compliance, there is still no quantifiable measure of what a "visible" focus indicator should look like.
The simplest way to satisfy this requirement is to use an outline around the perimeter of a focused element that is at least 2 CSS pixels thick and has sufficient contrast (already covered by 1.4.11 Non-text Contrast). For other types of focus indicators – for instance, if your site only changes the colour, or adds an underline, partial border, or additional icon when an element receives focus, you will need to work out if this change has sufficient contrast with the non-focused state, and if the overall size/area of change is large enough.
For more information read our post Foundations: visible focus styles, as well as Understanding SC 2.4.13: Focus Appearance (Level AAA).
All functionality that uses a dragging movement for operation can be achieved by a single pointer without dragging, unless dragging is essential or the functionality is determined by the user agent and not modified by the author.
Sites that rely on dragging movements – such as drag-and-drop functionality, draggable carousels, maps that rely on dragging for panning, or sliders – can be problematic for users that do use mouse/touch inputs, but lack the necessary dexterity to confidently and reliably perform those movements. In these cases, a site must provide an alternative way for a mouse/touch user to still perform the same actions.
This criterion patches a gap from WCAG 2.1: that version introduced 2.5.1 Pointer Gestures (Level A), but that criterion was specifically scoped to path-based gestures. The new 2.5.7 Dragging Movements requirement applies more broadly to "freeform" dragging movements which are not necessarily path-based, but can still be problematic for certain users.
Make sure that there is a way for a mouse/touch user to still perform the same action using simple clicks/taps, rather than being forced to perform a dragging movement. For drag-and-drop interfaces, this could be achieved by allowing a user to click/tap on an item to "pick it up", and a subsequent click/tap to "drop it". For maps, add explicit directional buttons to pan the map view. For carousels, provide previous/next controls, or "dots" underneath the carousel to jump directly to a particular slide. For sliders, make sure that users can click/tap directly on the slider's "track" to move the slider to that particular position.
Note that a keyboard alternative (already covered by 2.1.1 Keyboard) is not necessarily sufficient to pass this requirement. Users must be able to perform the action using mouse/touch, and can't be expected to switch to a keyboard instead.
For more information read our post Foundations: pointer gestures, as well as Understanding SC 2.5.7: Dragging Movements (Level AA).
The size of the target for pointer inputs is at least 24 by 24 CSS pixels, except where:
- Spacing: Undersized targets (those less than 24 by 24 CSS pixels) are positioned so that if a 24 CSS pixel diameter circle is centered on the bounding box of each, the circles do not intersect another target or the circle for another undersized target;
- Equivalent: The function can be achieved through a different control on the same page that meets this criterion;
- Inline: The target is in a sentence or its size is otherwise constrained by the line-height of non-target text;
- User agent control: The size of the target is determined by the user agent and is not modified by the author;
- Essential: A particular presentation of the target is essential or is legally required for the information being conveyed.
Activating small targets can be challenging for people who have difficulty with fine motor movement. In particular, when small targets are in close proximity, the wrong target may be activated by mistake. WCAG 2.1 tried to address the problem already with 2.5.5 Target Size (now renamed to 2.5.5 Target Size (Enhanced)) at AAA, setting a minimum target size of 44 by 44 CSS pixels.
On the surface, the new 2.5.8 Target Size (Minimum) criterion also defines a minimum target size of 24 by 24 CSS pixels. However, even if a target falls below this minimum, it can still pass this criterion if it provides sufficient spacing.
The simplest way to satisfy this criterion is to make sure that targets are at least 24 by 24 CSS pixels. Otherwise, at least provide sufficient spacing around each target: for each target, make sure that there at least a circular area with a diameter of 24 CSS pixels, centered on the target, that does not contain any other targets and does not intersect with any other spacing circles of adjacent targets. While the spacing clause in effect allows for targets that can be as small as a single 1 by 1 CSS pixel area, it at least prevents small targets from being placed too close to each other, leading to users accidentally activating the wrong target.
There are further exceptions for targets that have an equivalent alternative that does have a sufficient size, inline targets, targets whose appearance is fully controlled by the browser, and for targets that – because of their very nature, such as points on a map – have to be at a particular small size.
For more information read our post Foundations: target sizes and Understanding SC 2.5.8: Target Size (Minimum) (Level AA).
If a Web page contains any of the following help mechanisms, and those mechanisms are repeated on multiple Web pages within a set of Web pages, they occur in the same order relative to other page content, unless a change is initiated by the user:
- Human contact details;
- Human contact mechanism;
- Self-help option;
- A fully automated contact mechanism.
People who need help can find it more easily if it's in the same consistent place across all pages.
Note that this criterion does not mandate that sites must provide help mechanisms. Only that if they do, the order is consistent.
If your pages offer a help mechanism, make sure that the relative order of the help mechanism (or the link to reach said mechanism) is always in the same order relative to other page elements.
This criterion is explicitly concerned with the focus/source order. Whether or not the visual position of the help mechanism is the same across pages is not important for this criterion, though as a best practice, you should aim for visual/layout consistency as well.
For more information see Understanding SC 3.2.6: Consistent Help (Level A).
Information previously entered by or provided to the user that is required to be entered again in the same process is either:
- auto-populated, or
- available for the user to select.
Except when:
- re-entering the information is essential,
- the information is required to ensure the security of the content, or
- previously entered information is no longer valid.
If, as part of the same process, users are asked to re-enter the same piece of information multiple times, it increases the cognitive burden for a user, as they have to remember what they entered previously. It also increases the chance that they may make a mistake.
This criterion requires that users should generally not be asked to re-enter information they previously provided as part of the same process multiple times.
In general, avoid making users re-enter the same information multiple times as part of a process. If, for whatever reason, it is necessary to ask for the same information more than once, prefill/auto-populate the form fields already, or provide users with a way to select the previously entered information.
An example of this is a classic checkout process on an e-commerce site. At the start of the process, the site asks for a shipping address. In the billing part of the same checkout process, it will typically ask for a billing address. As it's common that both the delivery and billing address are the same, instead of having to explicitly fill in the same address again, users can just select a "same as shipping address" option.
For more information see Understanding SC 3.3.7: Redundant Entry (Level A).
A cognitive function test (such as remembering a password or solving a puzzle) is not required for any step in an authentication process unless that step provides at least one of the following:
- Alternative: Another authentication method that does not rely on a cognitive function test.
- Mechanism: A mechanism is available to assist the user in completing the cognitive function test.
- Object Recognition: The cognitive function test is to recognize objects.
- Personal Content: The cognitive function test is to identify non-text content the user provided to the Web site.
Authentication often relies on a cognitive function test, such as remembering a username and password, manually entering a one-time passcode, or solving a calculation or puzzle. People with cognitive disabilities may find these tasks difficult or impossible to complete.
The simplest way to satisfy the criterion is not to have any cognitive function tests as part of an authentication process.
If the authentication process does have a cognitive function test, provide an alternative that does not rely on it - for instance, fingerprint authentication (via platform functionality like Windows Hello), open authorization (OAuth), use of a physical key/dongle, or app-based authentication (where a user opens a separate application and confirms that it is indeed them trying to log in).
Remembering and entering a username and password also falls under the definition of a "cognitive function test". In these cases, the simplest way to meet the requirement is not to prevent copy/paste functionality on the login form fields, and allowing the use of password managers to autofill the fields, rather than having to manually type them in – this counts as a "mechanism". The same is true for passcodes (such as TOTP codes): a user must be able to copy/paste these, rather than having to manually transcribe them.
This success criterion includes exemptions for "object recognition" – such as the classic "select all squares that contain a particular type of object" tests – and being able to recognise "personal content" – for instance, images that the user has previously uploaded to a site.
Note that this criterion (and its AAA counterpart) only apply to authentication – when a user logs into a site. They do not cover other situations where cognitive tests (such as CAPTCHAs) are presented to the user.
For more information see Understanding SC 3.3.8: Accessible Authentication (Minimum) (Level AA).
A cognitive function test (such as remembering a password or solving a puzzle) is not required for any step in an authentication process unless that step provides at least one of the following:
- Alternative: Another authentication method that does not rely on a cognitive function test.
- Mechanism: A mechanism is available to assist the user in completing the cognitive function test.
This is the matching AAA version of 3.3.8 Accessible Authentication (Minimum). It is the same as its AA version, but without the exception for "object recognition" and "personal content".
For more information see Understanding SC 3.3.9: Accessible Authentication (Enhanced) (Level AAA).
While WCAG itself is not a law, it is used as a reference/benchmark for accessibility-related legislation. For instance:
As WCAG 2.2 has been released as a stable W3C Recommendation, now is the time to familiarise yourself with the new success criteria, and to integrate them in your own accessibility and design considerations.
While you may find that you're already compliant with some new criteria already, since they just clarify/enshrine best practices, others – such as 3.3.8 Accessible Authentication (Minimum) – may require more fundamental changes to existing processes and systems.
For our part, all new assessments at TetraLogical are based on WCAG 2.2 as a matter of course. We're doing this because we believe that each new version of WCAG offers a better experience for people with disabilities, irrespective of the version cited in law.
For more information about the Web Content Accessibility Guidelines, read our WCAG primer or browse our training courses and training programmes.
With thanks to Graeme Coleman for his contributions to this post.
Updated: 11 October 2023
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。