FAQ on WCAG 2.2 - The New Standard for Accessibility
What does WCAG mean?
What is WCAG 2.2?
How are automated testing rules for WCAG 2.2 introduced?
Why is WCAG 2.2 being released?
How will WCAG 2.2 impact laws and legislations?
New success criteria for WCAG 2.2 explained
Where can I learn more about WCAG 2.2 and testing rules?
What does WCAG mean?
WCAG stands for "Web Content Accessibility Guidelines".
WCAG is the international standard for web accessibility, developed by the (World Wide Web Consortium) W3C, the internet standard organization that is also responsible for HTML and CSS standards. Siteimprove is a member of the W3C and actively participates in the standardization efforts within the area of digital accessibility.
What is WCAG 2.2?
In April 2023, W3C is expected to release nine new success criteria to WCAG, thereby introducing WCAG 2.2.
The success criteria for 2.1 will be backwards compatible with WCAG 2.2 with two exceptions:
- Success Criteria 2.4.7 Focus Visible changes from Level AA in WCAG 2.1 to Level A in WCAG 2.2.
- The Success Criteria 4.1.1 Parsing will become obsolete and removed from WCAG 2.2. More information about the removal of the criteria for Parsing can be found in the WCAG 2 FAQ.
How are automated testing rules for WCAG 2.2 introduced?
Shortly after the release of WCAG 2.2, Siteimprove will begin reviewing the criteria to see which could be validated through automated testing within Siteimprove platform.
Since 2017, Siteimprove has taken part in co-authoring a harmonized set of accessibility conformance rules (ACT) for conformance with WCAG 2 within W3C. The purpose of this work is to write a set of standardized rules measuring conformance with WCAG. The automating testing for WCAG 2.2 will be done in alignment with the ACT (Accessibility Conformance Testing) community group. Siteimprove will continue to push the envelope on what can be tested with automated methods.
For an introduction to test rules for WCAG 2.2, see the Understanding Test Rules for WCAG Success Criteria at the w3c.org website.
The Siteimprove Accessibility team will continue introducing new automated and semi-automated testing rules. If you would like to get first access and get involved with the development process and testing, you can read more on how to sign up for the Siteimprove Firstimprover program.
Why is WCAG 2.2 being released?
WCAG 2.0 was released in 2008, and WCAG 2.1 was published in 2018. Both technology itself and website usage have changed a lot since the introduction of the last version, and there’s a greater demand for optimal accessibility. For this reason, the standard for web accessibility needs to evolve.
The new criteria are expanding coverage for user groups that were not recognized in the earlier versions of WCAG. As additional research and information about user needs are now available, updates are needed. These updates include criteria addressing keyboard, mouse, and mouse emulator users and cognition criteria.
Examples of use cases for the added criteria are below.
Keyboard:
“I can’t see where I am on the screen?”
“It takes a long time to re-type my information.”
Mouse and mouse emulators:
“I don’t have the dexterity to drag things.”
“It is very hard to hit small buttons.”
Cognition:
“I can’t get past the sign-in step.”
“Suddenly I can’t find where to get support.”
How will WCAG 2.2 impact laws and legislation?
WCAG 2.2 is expected to be promoted to an official W3C Recommendation in April 2023. It is also expected that legislations that refer to WCAG will eventually be updated to the newest version of the standard, but this will not happen immediately.
The EU Web Accessibility Directive that came into force in EU member states on September 23rd, 2018 references WCAG 2.1 as the standard to be used. It is not clear when it will get updated to WCAG 2.2, but it’s expected.
In the US, Section 508 references WCAG 2.0. It is not clear when it will get updated to WCAG 2.1. or 2.2.
The Americans with Disabilities Act (ADA) says the web must be made accessible, but it doesn’t reference any standard. WCAG 2.0 is widely considered the de facto standard for ADA compliance. Nevertheless, we anticipate that there will be an increasing expectation for websites to live up to WCAG 2.1 and likely 2.2 as well.
The Accessible Canada Act (ACA) was passed by the government of Canada on June 21, 2019, bringing accessibility legislation to the federal level for all provinces. The expectation is that the ACA will strive to adopt the latest standard for web accessibility.
New success criteria for WCAG 2.2 explained
The new criteria for Focus Appearance defines what it takes for users to be able to clearly see the focus indicator, when they are navigating a website with a keyboard.
In WCAG 2.1, we already have a criterion called “Focus Visible” that requires you to ensure that some marking on the page exists to show where users are located when navigating using a keyboard. This marking is called a focus indicator—or focus styling. If the focus indicator is not easy to detect, it’s still practically impossible for users to perform any task. It would be like trying to use a mouse with an invisible mouse cursor.
The focus appearance requirements are as follows:
Color contrast:
- 3:1 ratio against surroundings, or
- 3:1 ratio between focus and non-focus states
Size/shape:
- Solid border, or
- As large as a 1px solid border, or
- As large as a 4px solid line along the shortest side
Note that this criterion is marked as “at risk” due to the complexity of testing for it.
2.4.12 Focus Not Obscured (Minimum) (AA)
The purpose of this Success Criterion is that focus styling must never be completely covered by other elements.
Imagine, a keyboard user browsing the footer of a website, when suddenly a chat widget pops up and covers a part of the footer, including the focus indicator that is left under the chat widget. In this case, the user will likely struggle to figure out where their focus indicator went. These are a couple of examples. Other ways to pass might exist, but the core of the success criterion is to make sure that no interactive element ends up being completely covered by another floating element.
For following this criterion, there are a couple of things you can do.
For instance:
- You could make sure that overlays, dialogs, dropdowns, or tooltips, that can stay open, will not cover things that the user can tab to. You also must consider if it can happen on other screen sizes, like on a smartphone.
- You could also pass by making sure that it is not possible at all to Tab outside of the Chat Widget, until the user closes it. This is called “focus trapping” – when the focus cannot leave the Chat Widget until you close it.
2.4.13 Focus not Obscured (Enhanced) (AAA)
This criterion is similar to 2.4.12, with the difference that this enhanced criterion requires that no part of what is being focused on can be obscured.
In practice this criterion requires that people be never forced to re-order or move things around by mouse-dragging only. There needs to be an alternative way.
The criterion aims to help users who can use a mouse, but do not have the fine motor control to hold down the mouse button while moving the mouse or users who are using mouse emulating assistive technology, like eye-tracking software, where dragging motion may be hard to achieve. These are only a couple of examples. There exists a myriad of these types of tools.
Imagine, you are working on something that requires the user to drag an item. For instance, a slider control. While most sliders have support for clicking somewhere on the line to move the bullet, it can be difficult to hit the exact value. Especially if the slider covers a broad range of numbers, let us say, 1 to 100. Hitting 32 on such a slider would be tricky. In this case, we can satisfy the criterion by adding a simple “minus” and “plus” button. Or better yet an input field to add the preferred value.
Another common example that could fail this criterion would be a list of items that can be re-arranged with drag and drop. You must ensure that you support moving the items with a single click.
2.5.8 Target Size (Minimum) (AA)
The purpose of this Success Criteria is to make it easy for mouse users, eye-tracking users, switch device users, and others to be able to hit any button or link they intended – and minimize the risk of hitting the wrong button due to buttons being too small and sitting too close together.
The requirements for target size of any clickable element are:
- Size is 24x24px
- Size + spacing gives 24px to nearby clickable elements
The aim is that people can easily learn where to find help and support when they need it.
As an example, if you have any help options or support resources on your site, be those contact details, chat widgets, help center articles, anything of the sort, and if the user can find them on more than one page, then this criterion applies.
Let us say, the website has a chat widget, and it is floating at the bottom of the page content, as they usually do. It must remain in the same location visually but also in the order when tabbing with a keyboard, on all applicable pages. This makes the location of help predictable for the website users.
You can use the Siteimprove Policy product to make sure that any Help link or contact details exist in the footer on all pages, for instance.
This criterion requires that services do not require people to spend time entering the same information twice. This is particularly useful for those where typing can be difficult or draining of their energy. For instance, when filling out a form, you should not need to add your home address twice, unless it would be for security purposes.
In order to pass this criterion, when asking for information that is already previously entered in a process, it needs to be auto populated or available for the user to select.
3.3.8 Accessible Authentication (AA)
The purpose of the Criterion is to help users to log in more easily, without compromising on security.
To pass this criterion, authenticating should not require users to:
- Remember a password
- Solve a puzzle or question
Unless:
- An alternative way of logging in is offered
- It supports Password Managers or copy-pasting passwords
- The user must recognize objects or the user’s own non-text content
In practical terms, for password fields, you simply have to make sure you don’t block any so-called Password Managers, and that you do not restrict copy-pasting a password into the password field. Many browsers support remembering users’ passwords. You can also help this along if you add the HTML attribute called `autocomplete` on the password field. You actually have to write code specifically for disabling these things, so as long as you don’t deliberately work to avoid Password Managers or copy-pasting, you’re good.
Recognizing common objects, using CAPTCHA, is allowed for AA level, but not for AAA level, which is why we do advice against them.
3.3.9 Accessible Authentication (Enhanced) (AAA)
This is a stricter version of the 3.3.8 criterion, where the requirements are the same, but except CAPTCHA. You are not allowed to require the user to recognize objects or their own content on AAA level. Recognizing street signs, for instance, might pose an issue for people who live in a country with different street sign designs.
Where can I learn more about WCAG 2.2 and testing rules?
- Everything you need to know about the WCAG 2.2 update (Siteimprove)
- What’s new in WCAG 2.2 (W3C)
- Understanding Test Rules for WCAG Success Criteria (W3C)
Did you find it helpful? Yes No
Send feedback