Website accessibility professionals around the world have been watching for the newest version of the Web Content Accessibility Guidelines (WCAG) to be released, and the wait has ended. Let’s look at the new WCAG version 2.2 and see what it means for those who design, develop, own, and manage existing conformant sites or for those who wish to create a new, accessible site.
Prior WCAG versions are not invalidated
WCAG 2.2 does not replace versions 2.0 or 2.1. Instead, it adds clarification to the existing guidelines. Further, the latest guidelines add more techniques for providing enhanced accessibility for those with mobility and cognitive disabilities. So, if you have a website that was built and maintained following the Guidelines in versions 2.0 or 2.1, you do not need to “upgrade your site” to meet these standards. However, you should seek to scan your site against the latest standards and continue to edit your site to remain compliant.
That status of WCAG 2.2 in automated testing tools
Some website accessibility testing tools have draft rules to report on potential WCAG 2.2 violations, but all tools do not yet have the ability. And all tools, even if they can already report on 2.2 issues, will be further updated as more is learned about the rules, how to interpret them, and how to best fix them. In other words, if a tool does not report on a potential issue now, you can expect that in the coming months, it will.
Mobility Enhancements in WCAG 2.2
When items have keyboard focus, the entire component can’t be obscured by other items. This is commonly encountered with elements like a cookie banner, a sticky menu, or a chat service, so is something to be considerate of during the design and development phases, or when adding new features to an existing site. Note that modals and similar are not an issue. Here are examples of how to satisfy this guideline:
2.4.12 is the AAA version of this rule that states that the entire item with focus is visible. In 2.4.11, if part of the focus indicator is visible, the test is passed. While ensuring that the entire element is visible is not required, it is a best practice that it is, and ZAG will seek to meet the AAA standard.
Finally, if an element can be moved and the end-user chooses to place the element on top of an element that can receive focus, that is not a violation of this Guideline.
When last we wrote about WCAG 2.2, Focus Appearance was a AA requirement and unfortunately it has been made a AAA guideline with WCAG 2.2. Focus Appearance mandates that the focus indicator box has at least a 3:1 color contrast ratio and that the lines that make the border be at least 2 pixels. When manually testing websites, ZAG will continue to consider this as an important accessibility feature that should be on all sites, not just AAA sites. Note that ZAG has been meeting this standard since the release of 2.1 in June of 2018 and we will continue to do so. After all, what good is a focus outline if some visitors can’t actually see it?
Dragging an element online is deceptively a physically difficult proposition for someone with a disability. Dragging a mouse involves tapping at a starting point, holding down the button, moving the mouse while holding down the button, and releasing the button at the proper end point. If there is any functionality that requires movement like this, here’s how to satisfy that with this new guideline:
- If this functionality exists, you should also provide a way to accomplish the same with single-pointer actions. For example, if there is a file upload feature where one can drag a file into an area this should also include an “upload” button.
- More commonly, if there is a slider and one can only drag the slides to change the visible slides, this would fail. The easiest solution is to have arrows or clickable slide indicators as part of that slider.
All targets (clickable elements) must be 24px wide. An element can be less than 24px if the element and space around the element amounts to at least 24px. This should be considered as a general usability best practice but should be a particular focus when designing mobile versions of sites or mobile apps – for example in areas where there is a touch target element.
This doesn’t just apply to touch screens, but also mouse users who might struggle to accurately target and click a link. Examples of common site elements that will fail this requirement are pagination which is common on search result and blog main pages.
Some exceptions to this rule include:
If a link, for instance, is available elsewhere on the page with a proper target size, the link can be available in violation while the page remains accessible.
Links within a block of text like a paragraph or sentence.
Controls provided by the browser. Elements the browser might control include some radio buttons, some calendar controls, dropdowns, etc.
Links on a map.
Finally, if you display a government form on your site, that does not require this spacing because it’s a legal mandate that the digital version matches the paper version.
Finally, if one can zoom into a page to make a target bigger, seemingly bigger than 24 pixels, that does NOT allow one to pass this requirement.
Cognitive Enhancements in WCAG 2.2
As an A level guideline, this will apply to all sites but has been a best practice at ZAG for more than a decade. The standard is that if help is provided, it must be in a consistent location so that one always knows how to find it. Importantly though, good usability for all sites should consider this as a best practice – whether it’s a requirement or not. Importantly this pertains to web pages and not content that can be downloaded like a PDF.
If information was already provided by the user, the redundant entry guideline simply says that you can’t make a user enter it again. Instead it can be auto-populated (e.g. same billing address as shipping fields) or somehow available for the user to select. This is a usability best practice so should be something site owners already adhere to, but this guideline now makes it a checklist item. Note that the exception to this is if the information must be repeated for security purposes or because it has become invalid.
Needing to recall, transcribe, perform calculations, or solve puzzles are examples of a “Cognitive Function Test” and these cannot be used as the sole way to gain access to a site. For this reason, this guideline specifies that “When a cognitive function test is used, at least one other authentication method must be available which is not a cognitive function test.” In other words, one must be able to log in to a site without needing to memorize a username or password or to transcribe characters in an image or identify which parts of an image are a fire hydrant. Here’s how to satisfy this new guideline and whether it applies to your site or a vendor’s site you integrate with:
If you are reliant on a third-party vendor’s code, you will need to talk with that vendor about their plans to update their experience for accessible authentication.
If you manage an authenticated portion of your site, you will need to determine if your current solution needs to be updated. For instance, you might need to add a “Send me a sign-in link” near “Forgot Password.”
With two-factor authentication (2fa), this is already becoming an easier possibility, but note that one cannot require a user to know their username before a link is sent to their email or text messages.
Note that this does not apply to CAPTCHAs used for form submissions, only site authentication.
A cognitive test can be used in the following scenarios:
Alternative – Another method is included that isn’t a cognitive test
Mechanism – Help is included with the cognitive test to ensure the user can use it
Object Recognition – The cognitive test involves the ability to recognize an object
Personal Content – Content provided by the user is used as the cognitive test.
Removed from the Guidelines
4.1.1 Parsing (Obsolete and removed)
It is uncommon for previous guidelines to be removed, but WCAG 2.2 is removing success criterion 4.1.1 mostly because it’s obsolete due to how technology has changed. Usually, we see this standard referenced when there are duplicate IDs. Duplicate IDs can cause issues and if that is the case, the issue will run afoul of a different standard even if 4.1.1 no longer exists. This won’t require any action on behalf of site owners. (The standard remains in WCAG 2.2 to preserve numbering though it is marked “Obsolete and removed” in the documentation.)
What does this mean now and going forward?
For site owners and managers with a website ADA plan already in place, this new version should have little impact. Sites should be designed, built and managed against the latest guidelines and scanning tools should be in place to identify violations. Furthermore, website accessibility pages should be clear about what version of WCAG the site was built against which should thwart any predatory lawsuits.
To discuss your site’s specific ADA conformance needs, ZAG Interactive is always here to help, so contact us.
To learn more
, visit our Accessibility FAQs.