On January 25th, 2023, the W3C released a revised version of the WCAG 2.2 draft, incorporating feedback from the previous version published in October 2022. Earlier this month, the W3C published a notice of updates that would be integrated into the January Candidate Recommendation in the coming weeks. These standards are still in the candidate stage, but the W3C recently shared that WCAG 2.2 is scheduled to be completed and published in Q3 of this year.
This article will discuss the guidelines’ background and evolution, the new features in the latest update, and WCAG 2.2 release.
Evolution of the Web Content Accessibility Guidelines (WCAG)
WCAG 1.0 was the first release of any formal guidelines on web accessibility in May of 1999. Ironically, perhaps, this was less than a year after Google was founded in September 1998!
In 2008, the WCAG guidelines were updated to version 2.0, quickly becoming the more formally recognized standard. This is mainly because WCAG 2.0 introduced a more comprehensive and user-friendly set of guidelines that can be easily implemented in web and digital content.
Since its release, WCAG 2.0 has become the international standard for web accessibility. Many governments worldwide require compliance with the guidelines – specifically WCAG 2.0 AA – as a minimum requirement for web accessibility.
The WCAG 2.1 is a minor update to the WCAG 2.0 guidelines released by the W3C in 2018. It is currently the recognized standard as we wait for the upcoming 2.2 release. This update introduced 17 new success criteria to improve accessibility for users with cognitive and learning disabilities, low vision, and mobile devices. These guidelines are designed to keep up with the expanding technology and digital access.
Does WCAG 2.2 ‘break’ my accessibility progress? Do I need to wait till WCAG 2.2 releases before I start my web accessibility audit?
Let’s bust a myth quickly on the pending release of WCAG 2.2.
I hear concern from prospects and clients across the globe, on a nearly daily basis, that the release of the 2.2 success criteria will ‘break’ their digital accessibility progress to date or creates a scenario where they should ‘wait’ to kickoff an audit of their website or other digital properties.
There is a common misconception in the digital and web development community that WCAG 2.0 is no longer applicable and that web developers should only focus on complying with the newer versions, such as WCAG 2.1 and 2.2.
As outlined below, WCAG 2.2 does include new success criteria that address specific accessibility issues, but these are not intended to replace the existing WCAG 2.0 and 2.1 success criteria. In fact, the newer versions build upon the foundation laid by WCAG 2.0 and provide additional guidance for developers to create more accessible websites and digital properties.
It is also important to note that both regulations in the US under Section 508 and international regulations – such as EU Accessibility standards, the AODA, and many others – will continue to reference WCAG 2.0 AA as the standard for compliance when 2.2 is released soon.
We likely will, or should, see some updates to these regulations to recognize the updated version as the minimum standard for website and digital compliance, but as with any proposed rulemaking, this will undoubtedly take time – perhaps several years.
Therefore, if your team has a solid digital accessibility plan in place or is planning a website audit soon, WCAG 2.2 will not substantially impact your progress to date or a project audit you have designed.
Highlights of WCAG 2.2: What’s new in 2.2?
In the latest candidate recommendation for WCAG 2.2, released earlier this year, there are just 9 new success criteria. To that end, this is a more minor update to the guidelines and overall success criteria than WCAG 2.1 – especially considering a guideline is also being removed, as noted below.
Although this will only be the fourth WCAG version release in the guidelines’ history, we do have a few firsts slated with the new set of guidelines. In the current draft form, we would see the first guideline removed in any released version, with the 4.1.1 Parsing success criteria removed. This is due to enhancements to the current Assistive Technology (AT) versions. AT no longer has a need to directly parse HTML, so the W3C has determined the guideline is now obsolete.
Summary of the 9 new success criteria of WCAG 2.2:
2.4.11 Focus Not Obscured (Level AA) & 2.4.12 Focus Not Obscured (Enhanced) (Level AAA)
The purpose of 2.4.11 (and 2.4.12) is to make certain interactive controls, such as a link or button, have a visible and consistent focus state that is not obscured by other content on the page. In short, this means you can easily tell which button or link is currently selected, and other content on the page doesn’t get in the way.
2.4.13 Focus Appearance (Level AAA)
To ensure users who navigate web content without a mouse can easily recognize which control is currently active or selected, 2.4.13 requires that interactive controls, like buttons and links, should have a visible focus indicator with good contrast from its surrounding content and be distinguishable from non-focus states. When in compliance, users who use the keyboard or other ways to control the computer without a mouse can easily see which button or link is currently active or selected on a website. This guideline was updated to Level AAA in the May update.
2.5.7 Dragging Movements (Level AA)
The addition of 2.5.7 will apply to website features that require a user to do some form of drag and drop, such as moving items around on a page or sliding a bar. To comply with these new success criteria, a user should be able to perform these actions using a keyboard or other assistive technology, not just a mouse. The purpose is to ensure that everyone, including people who can’t use a mouse or pointing device, can still use these website features as they are often critical to the core user flow or consumer functionality.
2.5.8 Target Size (Minimum) (Level AA)
The new minimum target size guidelines mean that all clickable elements on a webpage, such as links and buttons, must be big enough for people with motor disabilities or those using touch screens to easily press. The goal is to ensure everyone, including those with disabilities, can easily click on the crucial parts of a webpage without difficulty or clicking surrounding content unintentionally.
In the current draft of the new 2.5.8 success criteria, these interactive targets would need to consume at least 24×24 CSS pixels of space – which can include white (non-actionable) space around said target. As an aside, this is a fantastic example of Accessible Design requirements pushing great Universal Design – we have all likely had an experience where attempting to ‘click’ or ‘press’ a very small button on the page engages another element we didn’t intend to enact!
3.2.6 Consistent Help (Level A)
At a baseline level, 3.2.6 states that when a website provides help and support information to its users, it should be consistent and easy to find across the entire website. The reason for this is simple and obvious: it ensures that a user can easily access the help and support they need without having to search (that may be pretty difficult or impossible) each time they seek help.
We can all agree this is especially important for users with disabilities who rely on this information to navigate the website more seamlessly and efficiently.
However, similarly to 2.5.8, this is another example of accessibility guidelines pushing a better experience for all – we can likely all agree that having consistent and easily accessible help and support information can also benefit all users.
3.3.7 Redundant Entry (Level A)
The new 3.3.7 success criteria are likely long overdue in creating highly usable experiences as it requires that when a user fills out the information on a website or app, they should not be required to re-enter the exact details repeatedly. The goal is to allow users to avoid repetitive data entry, especially those that could be forgetful due to varying forms of disabilities.
This is yet another new guideline that will holistically drive better UX of digital properties, creating more streamlined user flows and experiences for every visitor on a website or application.
3.3.8 Accessible Authentication (Minimum) (Level AA) & 3.3.9 Accessible Authentication (Enhanced) (Level AAA)
Authentication gained focus with 3.3.7 (and 3.3.8) as it outlines that any experience where you verify your identity on a website, such as entering a username and password, must be accessible to all users. The clear goal with this addition is to make sure that anyone can log in to a website and access its content and features, regardless of any disabilities they may have.
At a minimum, in the new 3.3.8 proposed success criteria, a cognitive function test – solving a puzzle or remembering a password – should not be required for any step in an authentication process if an alternative is not provided for such users.
Websites and log-in experiences should be designed to enable people with disabilities to easily complete the authentication process. This will increase their focus and make the process more efficient.
To read in-depth information regarding the nine new success criteria, please visit this page on W3C’s official website: W3C Candidate Recommendation Draft.
Is WCAG 2.2 official? When will it be released?
At the time of publishing this article, the W3C team was still working through final updates in the recommended draft from January after accepting feedback from the broader accessibility community. They have indicated that WCAG 2.2 will be released in the third quarter of 2023.
Stay tuned to our Allyant social media channels; we will keep our followers updated on any official release of WCAG 2.2 as soon as it is announced.
