The latest version of the Web Content Accessibility Guidelines, WCAG version 2.2, is finally coming soon, anticipated to formally move out of draft mode in the summer of 2023. Importantly, this version mostly comprises clarifications to previously issued WCAG 2.1 guidelines. Creating, retrofitting and managing your website, apps and other digital properties against these guidelines is extremely important to offering an inclusive experience to all visitors, no matter their abilities. Let’s dig into what website designers, developers, site owners and managers need to know about WCAG 2.2.
WCAG 2.2 clarifications to previous versions
Version 2.2 adds clarifications to several points to not only help end users but also site managers. Some of these may have more impact to some sites more than others, depending on your industry.
Not only must “user interface components” have visible keyboard focus indication, but they must be thick enough to be seen and must have a color contrast ratio of a least 3:1 relative to the background. Some designers and developers like ZAG Interactive had already been following this standard because it simply made sense to end users. Here’s how to satisfy this new guideline:
-
Include a 1 pixel border surrounding the element.
-
Add a 2 to 4 pixel “block” along the shortest edge of an oblong object.
-
Add a 3 pixel “underline” along at least one long-edge of an oblong object.
-
Note that a color change is acceptable as a “Focus Appearance” modality, but only if multiple items are near each other and the one with focus is different.
-
Only use solid lines for the border (i.e., avoid dotted lines)
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 or a sticky banner, so is something to be considerate of during the design and development phases. Note that modals and similar are not an issue. Here is how to satisfy this guideline:
While most businesses and organizations adhere to WCAG level AA standards, some may need to follow AAA guidelines. In this case, this guideline specifies that not even a single pixel can be obscured in any way on the website.
Dragging an element 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.
All targets, except links within text, 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 guideline is only applicable to sites that must adhere to level A guidelines, and specifies that every page that includes help or a link to help must include it in the same location. Importantly this pertains to web pages and not content that can be downloaded like a PDF. Importantly though, good usability for all sites should consider this as a best practice – whether it’s a requirement or not.
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 into 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 traffic light. 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, we 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.
This guideline only applies to level AAA and includes more restrictive exceptions than are allowed for the AA version 3.3.7. For AA, a cognitive test can be used if one of the following is provided:
-
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.
In this enhanced Guideline, only Alternative and Mechanism are allowed to be used.
If information was already provided by the user, this guideline simply says that you can’t make them enter it again. Instead it can be auto-populated (e.g. same billing address as shipping) 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 for this is if the information must be repeated for security purposes or because it has become invalid.
WCAG 2.2 – Removed 4.1.1 Parsing Success Criterion
It’s uncommon for previous guidelines to be removed, but WCAG 2.2 is removing success criterion 4.1.1 Parsing mostly because it’s obsolete because of how technology has changed. Parsing is all about writing clean code such as having start and end tags. This won’t require any action on behalf of site owners.
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 very little impact. Sites should be designed, built and managed against the latest guidelines and scanning tools should be in place to identify violations. Automated ADA scanning tools will be updated to adhere to these guidelines, and ultimately site owners or their hired site managers will continue to be responsible for fixing any issues that have been identified. 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.