On August 11th, 2020, the W3C, Accessibility Guidelines Working Group (AG WG), released a DRAFT version of the Web Content Accessibility Guidelines (WCAG) version 2.2 for public comment. While the changes aren’t as significant as previous iterations to the WCAG, there are new requirements that will be important to implement moving forward.
WCAG 2.1 vs 2.2
One of the big changes in WCAG 2.2 is the promotion of “2.4.7 Focus Visible” from level AA to Level A. What this means, is that having a visible focus indicator on your website is now considered a fundamental accessibility requirement and should be implemented sooner than later.
In addition, WCAG 2.2 introduces nine new success criteria. The new success criteria include the following:
WCAG 2.2 Checklist
2.5.7 Dragging
This success criterion applies to functionality that requires the dragging of elements. Some common uses of draggable elements are sliders, Kanban boards, maps, and radial controls. Per this criterion, if your application implements such a feature, an alternative means of dragging must be provided for those who may be unable to drag elements, such as individuals with mobility impairments.
For more information: Feature Implementation Guidance
2.5.8 Pointer Target Spacing
This success criterion is focused on elements ensuring the space to click/activate a small element, without clicking an adjacent element, is sufficient. For example, if you were to have a small icon (e.g., profile icon) that has a “logout” icon next to it, you would need to ensure there is 44x44px of spacing around said icon. This could be accomplished via adding padding to all sides of the element or making the icon itself at least 44x44px. So for an icon that is 24 x 24px, you would need 10px of padding on all sides. Accessibility aside, this is a good practice to ensure mobile users can click on the intended element without “fat fingering” another element.
For more information: Feature Implementation Guidance
2.4.11 Focus Appearance (Minimum)
The next two criteria get into a bit of complicated territory. Use of focus indicators has been a requirement in WCAG 2.4.7, but it was pretty vague. The general intent of this success criterion is to provide some clarity to previous focus indicator requirements in the WCAG standard. In short, the minimum size of focus indicators must be greater than or equal to a 1 CSS pixel border of the focused control, or have a thickness of at least 8 CSS pixels along the shortest side of the element. In addition, the focus indicator must have a contrast ratio of 3:1 against all adjacent colors, or have a thickness of at least 2 CSS pixels. Lastly, the focus indicator cannot be entirely hidden by author-created content. There are some great examples in the WCAG 2.2 “understanding” section of this criterion and I highly recommend taking a look at it.
2.4.12 Focus Appearance (Enhanced)
This success criterion is only relevant for AAA, so if you are not attempting to comply with the most stringent standard(s), skip to the next item on the list. However, this success criterion is similar to the previous one. You must have a focus indicator equal to a 2 CSS pixel solid border around user interface components. Color contrast for the focus indicator must meet a ration of at least 4.5:1. In addition, no part of the focus indicator can be hidden by author-created content. In other words, 2.4.12 is almost identical to 2.4.11, just a little bit more stringent in its requirements.
2.4.13 Fixed Reference Points
This success criterion is a bit unique when compared to the ones found in WCAG 2.1. It is one of the first examples where WCAG has begun to apply to non-traditional content, in this case, electronic publications (or ePubs). An easy way to understand this one is the page references in print editions of a publication must be the same as the references in the electronic version. In addition, the page references should not change upon a user zooming into a page.
3.2.6 Findable Help
This success criterion applies to single page web applications and/or any set of web pages with blocks of content that are repeated on multiple web pages. The requirement is that a mechanism for obtaining help must be provided and have consistent logical ordering across all pages. At least one of the following help mechanisms should be included:
- Human contact details (e.g., phone number, email address, hours of operation)
- Human contact mechanism such as a messaging system, chat client, contact form, social media channel.
- Self-help option such as an up-to-date Frequently Asked Questions, How Do I page, Support page.
- A fully automated contact mechanism such as a chatbot.
The explanation for this criterion does make clear that it is not a requirement to have human support available at all times. However, there are some additional important requirements that should be examined in the “understanding” section of this criterion.
3.2.7 Hidden Controls
This success criterion applies to design approaches which involve the hiding of controls required to complete tasks, unless there is another user interaction (e.g., mouse-over an element to display a control needed to complete a step form). The requirement in 3.2.7 requires all controls necessary for completing a process to be visible without additional user interaction.
3.3.7 Accessible Authentication
This success criterion applies to authentication patterns used which require a user to perform a cognitive function test (e.g., prove they are a human). A widely used example of a cognitive function test is Google’s reCAPTCHA v3 (e.g., “identify which images include a particular object”). 3.3.7 requires that an alternative means for second-level authentication that does not make use of a cognitive function test. An acceptable example may be use of 2FA (so long as the 2FA solution does not require cognitive function tests either).
3.3.8 Redundant Entry
This success criterion is easy to comply with and is good practice even for users without disabilities. In short, if you have a multi-step process (e.g., a form), then information entered in the previous steps should not be required again. However, this does not apply to a break in user session (e.g., user returns after closing a session or navigating away).
How do the new guidelines impact your organization?
As a result of the WCAG 2.2 standard currently being in DRAFT form and subject to change, the immediate impact is minimal in the short-term. In the mid to long term, your application runs the risk of becoming non-compliant with the WCAG.
How can you provide feedback / input?
The W3C/AG WG is seeking feedback from the public and has indicated the proposed success criteria may be removed or changed based on said feedback. However, they have also noted that there will be no new success criteria added into the guidelines, only changes/removals.
If you would like to provide feedback, you may either comment on Github or send an e-mail to [email protected]. This will likely be the last update to WCAG 2.x prior to it being succeeded (tentative as to how, at this time) and comments are requested by September 18th, 2020. Do not miss out on your opportunity to contribute to the future of web accessibility!
What can your organization do to prepare?
The best step your organization can take to become compliant with WCAG 2.2 is to have an audit conducted by independent accessibility professionals, such as TestPros. Even if you were previously compliant with WCAG 2.0 and/or WCAG 2.1, there is a chance you will not be compliant with WCAG 2.2 soon.
TestPros offers full life-cycle services for accessibility compliance, to include but not limited to: initial accessibility assessments / gap analyses, accessibility regression testing, integration of automated testing solutions in CI/CD pipelines, remediation of non-compliant software, and training.
To learn more about our accessibility services, contact us or check out our services page!
