Imagine a place online where everyone, no matter their ability, can move around freely and easily, kind of like everyone’s got a VIP pass to the whole internet. That’s the dream behind the latest updates to the Web Content Accessibility Guidelines, or WCAG 2.2 for short. It’s all about knocking down those virtual barriers that can make surfing the web a tough ride for some folks.
WCAG 2.2 Introduces 9 New Criteria
As we dive into what’s new in WCAG 2.2, think about walking side by side with a bunch of different people. There’s Jenna, who’s a whiz with her keyboard navigation, and Tom, who prefers a simpler click instead of a tricky drag-and-drop to get things done. These updates are here to make sure people like Jenna and Tom—and maybe even you—don’t hit a dead end on the web.
The success criteria from WCAG versions 2.0 and 2.1 remain unchanged in 2.2, except for one notable update: The 4.1.1 Parsing criterion has been deemed obsolete and is excluded from WCAG 2.2. Here are the new additions.
Guideline 2.4 Navigable
- 2.4.11 Focus Not Obscured (Minimum) (AA)
Imagine you’re navigating a site using your keyboard, but every time you move to a new element, you lose track of where you are because the focus indicator vanishes into the design. That’s exactly what WCAG 2.2 aims to prevent. By ensuring that focus indicators are visible, users like Jenna, who relies on keyboard navigation due to her mobility disability, can easily follow along.
Pass Example: A shopping site uses bright borders around focused items, making it a breeze for Jenna to navigate through sales items.
Failure example: Keyboard users experience focus indicators that are not visible when in focus, making it challenging to identify the focused component.
- 2.4.12 Focus Not Obscured (Enhanced) (AAA)
Building on the previous criterion, this enhanced version ensures that when elements receive keyboard focus, they stand out distinctly. This prevents elements from being obscured, allowing users to better see where they are on the page.
Pass Example: A music streaming service adds a glowing effect to buttons when selected, making it easier for users to control the music.
Failure Example: The website allows keyboard focus, but the focused elements are visually obscured, hindering user interaction.
- 2.4.13 Focus Appearance (AAA)
This criterion emphasizes high-contrast focus indicators. Tom, who struggles with low vision, finds websites adhering to this guideline much easier to use, as the elements he’s interacting with are unmistakably highlighted.
Pass Example: An online library outlines books in a thick, contrasting border when selected, aiding Tom in his quest for new reads.
Failure Example: Focus indicators lack sufficient contrast or thickness, making them challenging to discern, especially for users with low vision.
Guideline 2.5 Input Modalities
- 2.5.7 Dragging Movements (AA)
The Dragging Movements success criterion takes a step forward and demands keyboard compatibility for dragging actions, a critical consideration for users with mobility disabilities. It underscores that all drag-based operations should ideally be accomplishable through single-pointer actions unless dragging is essential or determined by the user agent without author modification.
It ensures that users can operate draggable user interfaces not just using the keyboard but also with different input devices.
Pass Example: The website allows users to operate draggable user interfaces through both keyboard and different input devices by providing them a button to perform the same functionality.
Failure Example: Users with mobility disabilities struggle to perform drag-based operations because of the absence of a single pointer to operate, limiting their interaction.
- 2.5.8 Target Size (Minimum) (AA)
Ever tapped the wrong link on your phone? This guideline aims to prevent that by setting a minimum target size, making it easier for users, especially those with motor difficulties, to navigate accurately.This criterion mandates target sizes for pointer inputs must be at least 24×24 CSS pixels, except when:
- Spacing: Smaller targets are positioned to avoid overlapping with others or their 24px circles.
- Equivalent: Function can be achieved using a different control on the same page meeting this criterion.
- Inline: Target size is line-height constrained or part of text.
- User-agent control: Target size set by the user agent, unaltered by the author.
- Essential: Specific presentation is legally required or vital for conveying information.
Pass Example: A food delivery app increases the size of menu buttons, making it effortless for Grace, who has tremors, to order her favorite meal without frustration..
Fail Example: A food delivery app’s menu buttons are too small, making it difficult to interact accurately.
Guideline 3.2 Predictable
- 3.2.6 Consistent Help
Consistent help mechanisms across pages can significantly reduce confusion. For those with cognitive disabilities, finding the help option in the same place on every page means he can navigate the site with confidence.
Pass Example: A banking website places its chat support button in the same corner on every page, providing a reliable way to seek help.
Fail Example: Inconsistent placement of help mechanisms on a website creates confusion for users with cognitive disabilities, impacting their ability to seek assistance.
Guideline 3.3 Input Assistance
- 3.3.7 Redundant Entry (A)
This criterion ensures users can avoid redundant data entry while filling out a long or multipart form, it is a critical consideration for those with cognitive disabilities. Data already input by the user should either be automatically filled in or accessible for user selection in the same process, except when re-entering is vital, for content security, or when the prior data is no longer valid.
Pass Example: An online registration form for a conference pre-fills information for Lisa based on her previous entries, reducing her cognitive load.
Fail Example: A website lacks mechanisms to prevent redundant data entry, causing frustration for users with cognitive disabilities filling out forms.
- 3.3.8 Accessible Authentication (Minimum) (AA)
This success criterion mandates accessible authentication methods, including alternatives like text-based authentication, for users with disabilities. Cognitive function tests, such as password recall or object recognition, are not required in the authentication process unless the below conditions are met.
- An alternative authentication method is available that does not rely on a cognitive function test.
- A mechanism is provided to assist the user in completing the cognitive function test.
- Cognitive function test is to recognize objects or shapes.
- Cognitive function test is to identify non-text content like images that are provided by the user.
Pass Example: A website provides accessible authentication methods, and cognitive function tests are not mandatory unless alternative methods are unavailable.
Failure Example: A website enforces cognitive function tests without offering alternatives, creating barriers for users with cognitive disabilities.
- 3.3.9 Accessible Authentication (Enhanced) (AAA)
This criterion is an enhanced version of 3.3.8 Accessible Authentication (Minimum) and underscores the importance of making authentication methods accessible to users with disabilities while eliminating the need for cognitive function tests. This accommodation is particularly crucial for users with cognitive disabilities who may encounter difficulties when cognitive tests are required in the authentication process. Unless any of the below conditions are met.
- An alternative authentication method is available that does not rely on a cognitive function test.
- A mechanism is provided to assist the user in completing the cognitive function test.
Pass Example: A website holds authentication methods that are accessible without relying on cognitive function tests, ensuring flexibility for users with cognitive disabilities.
Failure Example: Mandatory cognitive function tests persist without providing alternatives, excluding users with cognitive disabilities from the authentication process.
Best Practices for WCAG 2.2:
Be ready to implement WCAG 2.2 by following the below practices for updating existing websites and also for developing new websites.
- Ensure focus indicators are visually distinct and readily visible for keyboard users.
- Provide single-pointer alternatives for all dragging actions
- Maintain target sizes for pointer inputs of at least 24×24 CSS pixels
- Maintain the same order of help mechanisms throughout a set of web pages
- Automatically fill in data that users have previously entered or Provide accessible options for users to select previously entered data.
- Offer alternative authentication methods not reliant on cognitive function tests.
WCAG 2.2 builds upon its predecessors, introducing new criteria and refining existing ones to cater to a broader range of accessibility needs. Following these updated guidelines is a commitment to support and include low-vision, cognitive, and motorically impaired users and provide them with equal and inclusive experiences. If you need help implementing WCAG 2.2, give TestPros a call
To learn more about TestPros’ WCAG services, visit our page here.
