WCAG 2.2 has landed, and it’s packing a punch with new and updated guidelines that will impact new and existing designs. It’s a victory for inclusive design as it addresses a number of nagging issues that were causing users headaches.
Yes, it will require some effort to remediate existing designs with these updates, but the payoff will be worth it as really at the end of the day, it’s an investment into making your product more inclusive and usable for everyone.
So, what’s in store with WCAG 2.2, and how do you, as a designer, integrate these changes? Let’s dive in!
Guideline 2.5 — Input Modalities
There are two changes in this guideline, which refers to improvements in functionality beyond keyboards.
2.5.7 Draggable Movements (AA)
What?
Dragging gestures that use a mouse should be replicated by a simpler pointer alternative, such as a tap or a click.
Dragging is a movement where you tap or click on an object to start, then press and hold while you move the pointer to a new location or end point, and release to drop the object.
Why?
Not all users can accurately press and hold an interface while also repositioning the pointer. Some functionality rely exclusively on dragging gestures and this could exclude users from the experience, such as this pace converter.
Who benefits?
Users with mobility impairments, tremors, and other conditions that affect their fine motor skills. The persona example from w3 is a retiree with a hand tremor.
How?
Identify where a dragging gesture is required and also make sure an alternative tap/click gesture is present, such as up/down or left/right buttons. It’s important to remember that there’s no universal solution for this one — it’s very context-specific. You might need to flex your creative muscles and think outside the box to find the most suitable alternative for your design. It’s about striking the right balance between functionality and accessibility, ensuring that all users can navigate and interact with your product effectively
Use cases
Use case 1:
Problem: A user needs to reorder a draggable list by priority, but they cannot hold the mouse button down and drag accurately enough to move the items on the list.
Solution: provide up and down arrows next to each item on the list that the user can click to change the order.
Use case 2:
Problem: A user is completing a psychometric test online and needs to indicate how much they identify with each statement using a Likert scale. However, they cannot hold the mouse button down and drag the slider accurately to the side.
Solution: Provide a scale of 1–10 next to the slider that the user can click to select their response. Additionally, provide a free text field next to the slider where users can input a numerical value if they prefer.
2.5.8 Target Size (Minimum) (AA)
What?
This update requires that all pointer inputs (such as buttons) must be at least 24x24 CSS pixels (px) in size.
Why?
This makes the controls easier to activate by ensuring that they are large enough and have enough space around them.
Who benefits?
Users with dexterity issues who find it difficult to accurately activate small targets, especially when they are close together.
How?
When designing your websites and apps, make sure that all pointer inputs have a minimum size of 24x24 CSS pixels. Use larger targets for more important or frequently used controls, and increase spacing between targets that are close together so that users are less likely to activate the wrong target.
There are a few exceptions to this rule, which you can learn more about on the W3C website.
Use cases
Use case 1 (from W3C)
Problem: A user is presented with social icons in a row in the footer content. The icons are circular but have a target of 20x20 CSS pixels. but have no space between them.
Solution: Implement a 4 pixel space between each icon is implemented so that the user can select the appropriate target.
Use case 2
Problem: A user is presented with a dropdown menu to select features of a product. The menu item targets (text and padding) have 18 pixels in height. The user is unable to accurately select the menu item.
Solution: Increase the padding so that the menu item target has a total height of 24px
Guideline 2.4 Navigable
This guideline provides ways for users to navigate, find content, and determine where they are.
2.4.11 Focus Not Obscured (Minimum) (AA)
What?
When a user focuses on an element on a web page with their keyboard, the element must be at least partially visible. Ideally, the element should be fully visible.
Why?
If a user cannot see the element with focus, they may not know where they are on the page and may become confused or end up on the wrong page. The element with focus indicates the current interaction point on the page.
For example, it’s really frustrating to navigate the Adore Beauty website by keyboard as there are no focus indicators (I accidentally typed ‘fucos indicators’ while typing this, which is my exact sentiment when I don’t see focus indicators on popular eCommerce websites!).
Who benefits?
Sighted keyboard users benefit from this requirement. For example, the w3 persona is a person with a repetitive strain injury who uses speech recognition software to navigate the web would benefit from being able to see the element with focus.
How?
When designing, keep in mind the tabbing order of the page and how keyboard users will navigate it. Consider the need and context of components such as sticky headers, footers, and non-modal dialogs.
If possible, design your pages so that the element with focus is always visible. However, this is not always possible with complex designs. In these cases, try to reduce the number of interactions where the element with focus is obscured.
Use cases
Use case 1
Problem: A user is presented with a sticky cookie banner and does not dismiss it before navigating the page with their keyboard. When they tab to items underneath the cookie banner, they cannot see the item in focus and as a result end up on the wrong page.
Solution: Use scroll padding so that the region used as the target region is always in view for the user.
Use case 2 (from W3C)
Problem: A webpage uses a sticky footer. When the user moves focus to items, some are hidden behind the sticky footer and they cannot see them.
Solution: The items behind the sticky banner are in view when in focus, and the user is able to see them when focus is moved.
Exceptions
There are two exceptions to the minimum focus not obscured requirement:
- If a user opens content that may obscure the component receiving focus.
- Where content in a configurable interface can be repositioned by the user. Note that per the draggable update, this should also be via an alternative to dragging gesture such as minimize, maximize or move controls.
2.4.12 Focus Not Obscured (Enhanced) (AAA)
This is a AAA success criterion that goes beyond the minimum requirements of 2.4.11 Focus Not Obscured (Minimum)(AA).
Instead of allowing the item in focus to be partially visible, this success criterion requires that the item in focus be fully visible and that no part of the component be hidden by author-created content.
2.4.13 Focus Appearance (AAA)
This success criterion goes beyond the minimum requirements of 2.4.13 Focus Appearance (Minimum) (AA) by requiring that focus indicators meet the following additional requirements:
- The contrasting area of the focus indicator must have a contrast ratio of at least 4.5:1 between the colors in the focused and unfocused states.
- The minimum area of the contrasting area must be at least double the area of a 1px thick perimeter of the unfocused component.
- No part of the focus indicator may be hidden by author-created content
Why?
These additional requirements help to make focus indicators even more visible and easier to use for all users.
Who benefits?
Sighted keyboard users, users with low vision, users with attention or short-term memory issues, and users who use switch controls or other assistive devices.
The W3C personas given are a reporter with repetitive stress injury who uses speech recognition software to navigate the web and a retiree with low contrast sensitivity.
2.4.14 Focus Appearance (Enhanced) (AAA)
What?
This success criterion goes beyond the minimum requirements of 2.4.13 Focus Appearance (Minimum) (AA) by requiring that focus indicators meet the following additional requirements:
- The contrasting area of the focus indicator must have a contrast ratio of at least 4.5:1 between the colors in the focused and unfocused states.
- The minimum area of the contrasting area must be at least double the area of a 1 CSS pixel thick perimeter of the unfocused component.
- No part of the focus indicator may be hidden by author-created content.
Why?
These additional requirements help to make focus indicators even more visible and easier to use for all users, including users with low vision, users with attention or short-term memory issues, and users who use switch controls or other assistive devices.
Who benefits?
The following users benefit from this success criterion:
- Sighted keyboard users
- Sighted users who use a device that utilises a keyboard interface (such as a switch or voice input)
- Users with low vision who may use a keyboard
- Users with attention or short-term memory issues
- Users who use switch controls or other assistive devices
W3C persona examples:
- A reporter with repetitive stress injury who uses speech recognition software to navigate the web
- A retiree with low contrast sensitivity
- A person with cerebral palsy who uses a switch control to navigate the web
How
When designing focus indicators, make sure that they meet the following requirements:
- The contrasting area of the focus indicator must have a contrast ratio of at least 4.5:1 between the colors in the focused and unfocused states. You can use a color contrast checker to calculate the contrast ratio of your focus indicator while designing, such as the Adee Accessibility Tool for Figma).
- The minimum area of the contrasting area must be at least double the area of a 1px thick perimeter of the unfocused component. This means that the focus indicator must be at least 2 pixels thick on all sides of the unfocused component.
- No part of the focus indicator may be hidden by author-created content. This means that you should not place any author-created content, such as sticky headers, footers, or modal dialogs, over the focus indicator.
Additional tips:
- Use a consistent focus indicator style throughout your website or app.
- Make sure that the focus indicator is large enough to be easily visible.
- Avoid using focus indicators that are too bright or flashy, as this can be distracting for users.
It is okay for only some of the focus indicator to have the required contrast ratio, such as an outline within a button.
If you need to use complex mathematics to work out if a focus indicator is large enough, it is probably a sign that you should use a larger indicator instead. The bigger the visible change when an item receives focus, the better for usability.
Examples:
- A button may change its background colour to a brighter colour when it has focus.
- A text input field may add a thick border when it has focus.
- A link may add a thick underline when it has focus.
Guideline 3.2 Predictable
Make web pages appear and operate in predictable ways
3.2.6 Consistent Help (A)
What?
Make sure help mechanisms are in the same place on all pages of your website. This includes human contact details, human contact mechanisms (such as a contact form or social media channel), self-help options (FAQs or support articles), and fully automated mechanisms (chatbots). It does not include interface-level help such as contextual help, spell checkers, and instructional text in a form.
Why?
When the placement of help is consistent, users can find it more easily. This is especially important for users with disabilities or other needs who may not be able to complete their user journey without assistance.
Who benefits?
All users benefit from consistent help, but it is especially beneficial for users with disabilities or other needs. The W3C persona is a supermarket assistant with cognitive disabilities.
How?
- When designing help mechanisms, make sure they are in the same place on all pages of your website or app.
- Choose a prominent location that is easy to find, such as the header, footer, or menu.
- Make sure the help mechanism is available within a few interactions at all times.
- Use a consistent design for your help mechanisms to make it easy for users to recognise them.
- Note that this criteria also includes making the help mechanism in the same DOM order when the page is serialised. This might be important to note during a developer handover.
An example I have come across recently is the Bupa website which has many, consistent help mechanisms in the header, mega menu, bottom-right corner, and footer.
Use cases
Use case 1(from W3C):
Problem: A supermarket assistant with cognitive disabilities needs to schedule a medical appointment online. The supermarket assistant has seen a chat option in some places before, but cannot find it now.
Solution: If the chat option is in a consistent location, such as the lower right corner of every page, the supermarket assistant can easily find it and get the help they need.
Use case 2
Problem: A user with special assistance needs needs to book intercity train tickets. The website has instructions to call a phone number to arrange special assistance, but the phone number is not in a consistent location.
Solution: The website should consistently display the phone number for special assistance in the same location on every page to enable to the user to book directly via phone.
Guideline 3.3 Input Assistance
This guideline helps users avoid and correct mistakes.
3.3.7 Redundant Entry (A)
What?
Information that was previously entered by or provided by the user must be either automatically populated or available for the user to select when it is required to be entered again in the same session.
The exceptions to this are when re-entering the information is essential, required to ensure the security of the content, or when the information is no longer valid.
Why?
It is frustrating for users to have to enter their information multiple times when completing online transactions. Reducing the need to enter information more than once can reduce the cognitive effort required and the need to recall information provided in a previous step.
Who benefits?
Users with cognitive disabilities, including short-term memory issues, users with mobility impairments, users of assistive technology, and all users.
How?
This one is more for the developers to implement, however it will be handy to include interactions or mechanisms to populate information that has already been entered or stored. Make sure to make note of this in developer handover notes as well in order to satisfy this requirement.
Use cases
Use case 1
Problem: A user is checking out online and is presented with a checkout form. They need to enter their billing address and delivery address, which are the same.
Solution: Implement a checkbox that says “Billing address the same as delivery”. When checked, the billing address will auto-populate to the delivery address.
Use case 2
Problem: A user has lost their car e-tag and is requesting a new one through an online portal.
Solution: When the user requests a new card, their address on file is displayed and they only need to verify that the details are correct before a new card is ordered to that address.
3.3.8 Accessible Authentication (Minimum) (AA)
What?
Don’t require users to solve a puzzle, recall something, or transcribe something in order to log in. This includes CAPTCHAs and other cognitive function tests.
Why?
Some people with cognitive disabilities can’t solve puzzles, memorize a username and password, or retype one-time passcodes.
Who benefits?
Users with cognitive disabilities, but really all users, because let’s face it who enjoys selecting traffic lights from trees in the middle of their user journey?
How?
Again this one is more important during the implementation phase, but it’s important to be wary of to not design with these tests, and catch them in Design QA.
Other tips for log in interactions:
- Support password entry by a password manager (such as Google Password Manager or LastPass) to reduce the need for users to remember their passwords.
- Allow users to copy and paste their passwords into a text field.
3.3.9 Accessible Authentication (Enhanced) (AAA)
This is an AAA level version of the above criterion that goes above the minimum requirements. It stops requiring users to recognise objects or user-supplied images or media in order to log in.
For example, a login form that requires to select the correct image of a cat from a group of images does not pass this criterion.
Remember that as a designer, you have a unique opportunity to make the web more accessible and inclusive by designing it that way from the get-go.
Most of these changes benefit all users, and not just users with disabilities, so you’re not just ticking boxes for compliance; you’re making a conscious effort to create a seamless and accessible experience for all users.
Good luck and happy designing!
