Are you an online business or website owner? If so, you must be aware of the critical changes in the Web Content Accessibility Guidelines (WCAG) 2.2! The World Wide Web Consortium (W3C) is expected to release the latest version of WCAG in May 2023. So stay ahead of the curve and ensure your website remains accessible to all users, including those with disabilities. Here’s what you need to know about the proposed changes — and how they will affect your current WCAG compliance. And remember, when WCAG 2.2 goes live, 216digital will be here to help.
Why is WCAG Changing?
WCAG is a set of guidelines designed to help make web content more accessible to people with disabilities. However, as technology and user preferences change, so must WCAG’s standards. Each new standard introduced is developed by the Web Accessibility Initiative (WAI). In 2021, WAI announced they were starting to work on the draft for WCAG 2.2, which is finally expected to be released sometime next month.
WCAG can be changed to add new success criteria or to change a current guideline’s conformance level. But, it will not remove any guidelines or change any language. Currently, WCAG 2.2 is based on the same three conformance levels as the previous versions: Level A, AA, and AAA.
Level A is the lowest level of conformance and the easiest to achieve with minimal impact on a website’s structure or design. It allows websites to be broadly accessible as it addresses the most basic access issues.
By meeting the success criteria for Level AA, websites are considered reasonably accessible as they offer a higher level of conformity than Level A. AA is most often used as the compliance standard in lawsuits and is usable for most people.
Level AAA is the highest level of conformance and the most difficult to achieve. It is not often used as a goal to strive toward since it is not feasible for most websites to have the resources to meet this level.
What’s Changing In WCAG 2.2?
WCAG 2.2 introduces nine new success criteria along with minor changes to the instructions accompanying several established guidelines. However, each of these criteria is still up for feedback and changes, so there’s no guarantee that all of them will make it into the final version of WCAG 2.2.
Here’s a quick overview of the new guidelines — and how each one can help address web accessibility issues:
Guideline 2.4 Navigable
2.4.11 Focus Appearance (Minimum)
Focus Appearance builds on two existing WCAG criteria, specifying the minimum requirements for focus indicators. The new guideline ensures that keyboard focus indicators are visible and easily distinguishable. They must have a clear border, are not obscured by other content, and have at least a color contrast ratio of 3:1 against the unfocused state and all adjacent colors.
The intent of WCAG 2.4.11 is to help low-vision users who use a keyboard for navigation. Users can quickly tell where they are on a page by ensuring the current focus point is visible.
2.4.12 Focus Not Obscured (Minimum)
Knowing the current focus point is essential for sighted users who use a keyboard or keyboard-like device. However, sticky headers, pop-ups, and other content can sometimes obscure focused elements while a user is browsing.
However, Criterion 2.4.12 requires user interface components not to be entirely hidden from other content on the page. This lets users easily track the current focus point and avoid confusion.
2.4.13 Focus Not Obscured (Enhanced)
Similar to 2.4.12, 2.4.13 requires that no part of the focus indicator is hidden by other content.
Guideline 2.5 Input Modalities
2.5.7 Dragging Movements
Drag and drop movements can be difficult and error-prone for many website users. Therefore, WCAG 2.5.7 requires that any functionality that uses a dragging movement for operation can also be achieved in other ways, like clicking. For example, a user could use a single tap, double tap, long presses, or path-based gestures instead of dragging an item. However, a dragging action is allowed when it is essential to the functionality of the content.
2.5.8 Target Size (Minimum)
When buttons and other clickable elements are small, they can be challenging to interact with for people with fine motor impairments. The purpose of 2.5.8 is to ensure that when users select a target with a mouse or other device, they can do so easily without activating other nearby targets. Therefore, all clickable elements, such as links, must be at least 24 by 24 CSS pixels in size and spacing between adjacent targets.
2.5.8 provides a level AA alternative to 2.5.5: Target Size (Enhanced), which was introduced as part of WCAG 2.1. However, 2.5.5 requires the target size for all clickable elements to be at least 44 by 44 CSS pixels.
Guideline 3.2 Predictable
3.2.6: Consistent Help
The goal of 3.2.6 is to ensure that all users can easily find help when completing tasks on a web page. For example, suppose a help feature — such as search bars and help buttons — is available on multiple pages of a website. In that case, it must appear in the same relative place an order on each of the pages where it appears. This is particularly beneficial for users with cognitive disabilities or limited web experience, as they can quickly access help when needed.
Guideline 3.3 Input Assistance
3.3.7 Redundant Entry
For people with cognitive disabilities, logging into a website or mobile app can be challenging. The 3.3.7 level AA guideline tackles authentication processes that require the user to remember, manipulate, or transcribe information. Websites that use cognitive function tests must provide at least one other authentication method.
For instance, asking users to remember a password is a standard cognitive function test. But suppose the website allows entries from password manager browser extensions. In that case, the website has provided them with a mechanism to complete the process.
3.3.8 Accessible Authentication (Minimum)
3.3.8 takes 3.37 further by not allowing any exceptions for cognitive function tests. For multi-step processes, 3.3.8 requires websites to auto-populate fields or enable users to select the information that they’ve previously entered. For example, suppose a website’s form requires the user to enter their address multiple times. In that case, the second field should either provide users with an option to select their address from the previous entry or auto-populate.
3.3.9: Redundant Entry ( Enhanced)
Similar to 3.3.7 and 3.3.8, 3.3.9 applies to the authentication process. However, 3.3.9 is a Level AAA guideline that does not require an authentication process unless that step provides an alternative authentication process or auto-populate.
Getting Ready for WCAG 2.2
While the full implementation of WCAG 2.2 may still be on the horizon, it’s never too early to start preparing. Here are some steps you can take to ensure a smooth transition:
- Familiarize yourself with the new success criteria and understand their implications for your website.
- Conduct an accessibility audit to identify areas that need improvement and align with WCAG 2.2 requirements.
- Update your website’s design, content, and functionality to address the new criteria and improve accessibility.
- Train your team on the importance of web accessibility and the new guidelines to ensure consistent implementation.
How Will the Revisions Affect My Current WCAG Compliance?
The transition from WCAG 2.1 to 2.2 will require some adjustments to your website, particularly in the areas of navigability, input modalities, predictability, and input assistance. However, these updates are designed to build upon the existing guidelines, so your current efforts will not be wasted. By proactively addressing these changes, you’ll ensure that your website remains compliant and accessible to all users.
When WCAG 2.2 Goes Live, We’ll Be Here to Help
When WCAG 2.2 goes live, you can count on 216digital to help you navigate the changes and maintain an accessible website. Our expert team will assess your website, provide recommendations, and implement the necessary adjustments to ensure your website meets the latest accessibility standards. Reach out to us today by scheduling a complementary ADA Strategy Briefing so that you can embrace the future of web accessibility with confidence.