Web Content Accessibility Guidelines (WCAG) help people create websites to work for disabled people. They remove common barriers that disabled people find when using the web.
The World Wide Web Consortium (W3C) is the author of the guidelines. These form international standards for web accessibility.
W3C has now updated these guidelines to WCAG 2.2. The update has 9 new tests that build on the previous guidelines, and 1 test has been removed.
This article will explain the new additions to the guidelines and Scope’s views on the changes.
WCAG explained
The guidelines include many different criteria marked at A, AA, or AAA levels. Global legislation often requires websites to meet AA standards.
It’s important to highlight the guidelines will not remove every issue for every user. Disabled people’s needs are diverse.
The new tests are:
- 2.4.11 Focus Not Obscured (Minimum) (AA)
- 2.4.12 Focus Not Obscured (Enhanced) (AAA)
- 2.4.13 Focus Appearance (AAA)
- 2.5.7 Dragging Movements (AA)
- 2.5.8 Target Size (Minimum) (AA)
- 3.2.6 Consistent Help (A)
- 3.3.7 Redundant Entry (A)
- 3.3.8 Accessible Authentication (Minimum) (AA)
- 3.3.9 Accessible Authentication (Enhanced) (AAA)
- 4.1.1 Parsing has been removed from the guidance
Focus Not Obscured Minimum and Enhanced
Some users navigate a page with the tab key to find interactive elements like buttons or links. This may be because they have:
- a mobility impairment
- a visual impairment
- a broken trackpad
Focus Not Obscured minimum and enhanced make sure that the items are visible when in keyboard focus. The minimum requirement is that the item is mostly visible. The enhanced requires the item to be fully visible.
Often items such as cookie banners or sticky items cover content on a page. These tests make sure that items in focus are visible to a user.
It’s important to have tests that focus on keyboard only users and their access needs.
Focus Appearance
When users tab around a page, elements that are in focus must be visible. Items often have a focus border around them. This criterion has a set of requirements that a focus border must meet.
The focus border must:
- have a colour contrast of 3:1 against the same pixels in and out of focus
- be at least as large as the area of a 2 CSS pixel thick perimeter of the unfocused item
This makes sure that it is clear to a user when an item is in focus.
Focus Appearance issues
We believe 2.4.13 Focus Appearance (AAA) overcomplicates focus border size. Scope recommends focus borders are very obvious and should be fully enclosed boxes.
This test also misses an important factor of contrasting colours. The update also does not mention colour contrast between the focus border and elements in focus. For example, a black focus border around a purple button could be hard to see for some users. Yet this would pass the test if the background outside the element was white.
Dragging Movements
Some users may be unable to click and drag an item with a mouse. They may be using keyboard only functions. Or they may be using a mouse and not have the motor skills to perform a click and drag function.
Any action that requires a dragging movement should have a suitable alternative. For example, a sorting activity that asks users to click and drag the correct answer to the statement. It should also have a function where users can use up and down arrows on the screen to move the statements into the correct order.
Target Size
There is already a test for target size in WCAG 2.1. The original test said interactive elements must be 44 by 44 CSS pixels. This has now moved to become the enhanced requirement.
The new target size test in WCAG 2.2 is a minimum requirement. It says that interactive elements on a page must be 24 by 24 CSS pixels wide. This is to make sure that users can click or tap on a button without making an error.
The test has exceptions. For example, if it’s an inline link or if the control has an alternative on the page that meets these requirements.
Consistent Help
Websites often have a help function. This could be human contact details, an automated chatbot system or a self-help guide. When these are included across several pages on a website, they should always be in the same location.
This helps reduce the cognitive load for some users who may need help throughout their journey on your website. It also simplifies access to things a user may need.
Redundant Entry
When filling in a form, any information you’ve already entered should be auto-populated. For example, if you’re buying something online and it asks for the shipping address. You may then have to fill in your details again for your billing address.
This can be very stressful for some users, and it increases the cognitive load on a user. Instead, it should:
- be auto populated
- be selectable in a drop-down
- have another function to autofill available
Accessible Authentication Minimum and Enhanced
Finally, there is accessible authentication. This has a minimum and an enhanced level. Both tests make sure that users do not have to perform a cognitive function test. This is where users must solve, recall or transcribe something to log in.
For the minimum requirement, there are exceptions. These are:
- if an alternative method is provided
- if there is a tool to help a user
- if the cognitive function test is to recognise objects
- to identify objects that a user-provided
To pass the enhanced requirement, a cognitive function test cannot be included. Unless there is an alternative way to log in.
We believe the focus on cognitive impairments in these tests is a great addition. It’s helpful to simplify the authentication process. But we recommend aiming for the enhanced requirement and avoiding authentication tests.
Authentication test issues
3.3.8 Accessible Authentication Minimum (AA) allows for object recognition. We believe this ignores some people’s difficulties with authentication tests. Difficulties can be caused by many things, like impairments and cultural differences.
W3C writes that:
some forms of object recognition may require an understanding of a particular culture. For example, taxis can appear differently in different locales. This is an issue for many people, including people with disabilities, but it is not considered an accessibility-specific issue.
We recommend avoiding any barriers for users to access content, even if they are not accessibility specific.