On October 5, 2023, the W3C formally released and recommended the updated WCAG 2.2 guidelines, incorporating final feedback from the previous draft published in early 2023. The formal recommendation of these standards by the W3C moved this update to the Web Content Accessibility Guidelines from the draft stage to the most up-to-date global conformance standards for digital properties.
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, 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.
WCAG 2.1 was a minor update to the WCAG 2.0 guidelines released by the W3C in 2018. These standards still apply as guidelines but have been expanded upon with the formal 2.2 release. The 2.1 update introduced 17 new success criteria to improve accessibility for users with cognitive and learning disabilities, low vision, and mobile devices. These guidelines, along with the 2.2 updates, are designed to keep up with the expanding technology and digital access.
Does WCAG 2.2 ‘break’ my accessibility progress?
Let’s bust a myth quickly on the 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 has ‘broken’ their digital accessibility progress to date or creates a scenario where they now need to rush to kick off an updated 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 now 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. The more recent 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 and 2.1 AA as the standard for compliance even though 2.2 has since been released, so conforming to these standards is not remotely obsolete.
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. The recently published notice of proposed rulemaking by the DOJ references WCAG 2.1 AA as the recognized standard. Whether the next or final drafts from the DOJ are updated to reference WCAG 2.2 is very much to be determined.
Therefore, if your team has a solid digital accessibility plan 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 formal recommendation for WCAG 2.2, released in October, there are just nine new success criteria. To that end, this is a 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 is only the fourth WCAG version release in the guidelines’ history, we do have a few firsts with the new set of guidelines. In the formal release, we have seen the first guideline deprecated 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 needs to parse HTML directly, so the W3C has determined the guideline is now obsolete.
Summary of the nine 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. This is primarily designed for users who rely on keyboard focus for usability.
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 after initially being a Level AA success criterion in earlier drafts.
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 (unless dragging is essential for functionality). To comply with these new success criteria, a user should be able to perform these actions under an alternative method, such as using a keyboard or other assistive technology commands, rather than requiring a user to hold down a pointer. The purpose is to ensure that everyone, including people who can’t hold down 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 touch screens to press easily. 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. This guideline is designed for users with motor or dexterity disabilities who may struggle to access small or tightly clustered controls.
Within the newly released 2.5.8 success criteria, these interactive targets or controls must be 24×24 CSS pixels in size – which can include white (non-actionable) space around said target. Under the final recommendation of 2.5.8 within WCAG 2.2, there are several exceptions to this requirement, including inline targets, equivalent functionality being available on the same page, the user agent determining the target size rather than the author or if there is an essential reason (such as a legal requirement) for the target being displayed in a form that does not meet this criterion. 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 tiny 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 unless the user initiates the change. Simply put, help mechanisms and/or contact information must be placed consistently across pages. 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 (which may be 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.
As with 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 who could be forgetful due to varying forms of disabilities. To confirm with 3.3.7, you should not make the user enter the same information more than once in a session or provide an option to select the previously entered information. There are exceptions to this guideline, such as when the information is required to ensure the security of the content or previously entered information is no longer valid.
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 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 – including the ability for users to copy/paste passwords or two-factor authentication security codes if they are not using object or personal content to verify a user’s identity. 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 WCAG 2.2 Recommendation.
WCAG 2.2 is Now Published!
As outlined above, the W3C formally recommended WCAG 2.2 as the most updated success criterion for digital accessibility on October 5, 2023. Upon the release of these updated guidelines, our team at Allyant was immediately prepared to support any, and call, clients on conforming to the latest and greatest WCAG standards.
