What WCAG 2.2 Means for Your Website

Back to blog

What WCAG 2.2 Means for Your Website

Posted October 05, 2023

AudioEye

Posted October 05, 2023

A progress bar that is updating, underneath a label that reads WCAG 2.2.
A progress bar that is updating, underneath a label that reads WCAG 2.2.

Ready to see AudioEye in action?

Watch Demo

WCAG 2.2 is now the official recommendation of the W3C. Here’s what you need to know about the latest changes.

Last Update: February 14, 2024

After two years of soliciting feedback, the World Wide Web Consortium (W3C) published the Web Content Accessibility Guidelines (WCAG) 2.2 as its official recommendation — establishing a new set of criteria for businesses to consider as they look to remain compliant with laws like the Americans with Disabilities Act (ADA). 

Notably, businesses that were compliant under the WCAG 2.1 Level AA standards may not be compliant under WCAG 2.2 — and it’s likely these requirements will change again in the coming years. This means additional testing and insights from certified accessibility experts is needed to ensure businesses stay compliant.

Below, we provide an overview of the new criteria and tips on how businesses can identify where their digital content is no longer compliant. We’ll also discuss how AudioEye simplifies this process, making it easy for organizations to meet evolving accessibility standards.

The Evolution of Web Content Accessibility Guidelines

Originally established in 1999, WCAG 1.0 was the first step in establishing accessibility guidelines for the web. The original guidelines were focused primarily on HTML and included 14 guidelines. 

The next version, WCAG 2.0, was created in 2008 and broadened its scope to include the four principles of web accessibility. WCAG 2.0 was introduced after substantial changes in technology and was applied to all digital content, including documents and mobile apps. 

WCAG 2.1 was released in June 2018 and builds on the principles in WCAG 2.0. It was a welcome update as WCAG 2.0 could no longer account for more recent advancements in technology and web use. The new guidelines include several new success criteria for improving web accessibility on mobile devices.

This leads to October 2023 when the latest version of WCAG was released. The guidelines include nine new success criteria that specifically focus on providing more support for users with low vision, cognitive or learning disabilities, and limited motor skills.

Because WCAG is considered to be the gold standard for website accessibility, Section 508 of the Rehabilitation Act requires federal agencies to comply with WCAG 2.0 A/AA. For private businesses, the Department of Justice (DOJ) has stated that to comply with the Americans with Disabilities Act (ADA), organizations must conform with WCAG recommendations.

A chart showing the three levels of WCAG conformance: Level A, Level AA, and Level AAA.

WCAG 2.2: What’s New and Why It Matters

As mentioned above, WCAG 2.2 includes nine new success criteria, which build on the 78 success criteria in WCAG 2.1. Each of these success criteria helps improve digital accessibility for three major groups: users with cognitive or learning impairments, users with low vision, and users with disabilities on mobile devices. 

The latest version of the accessibility guidelines also removed an older criterion that is now obsolete: WCAG 4.1.1: Parsing. This is the first time a success criteria has been removed from the guidelines, a testament to the guidelines’ adaptability to current digital trends. 

As with previous versions, the new criteria are broken into three conformance levels: A, AA, and AAA. According to the DOJ’s recently published notice of proposed rulemaking on website accessibility under Title II of the ADA, businesses need to conform to WCAG 2.X Level AA standards.

With that in mind, let’s go into the new criteria and how each helps address accessibility issues.

WCAG 2.4.11: Focus Not Obscured (Minimum) (Level AA)

For sighted users who rely on a keyboard to browse websites, knowing the current point of focus is a critical part of navigating pages. However, focused elements can occasionally be obscured by sticky headers, pop-ups, and other content that appears on the screen.

When a user interface component receives keyboard focus, WCAG 2.4.11 says that a portion of it must remain visible and not be obscured by other content on the screen. This can help improve focus and navigation for users with cognitive or visual impairments; however, the more visible the focus indicator is, the easier it is for users to follow as they navigate web pages.

WCAG 2.4.12: Focus Not Obscured (Enhanced) (Level AAA)

WCAG 2.4.12 follows the same guidelines as the previous criterion; however, the key difference here is that not part of the focus indicator can be hidden by other content on the page. This ensures that the item being focused on is entirely visible by the user which improves navigation for those with limited or low vision. Users with attention limitations (such as short term memory limitations) are also able to focus more easily with the entire focus visible.

WCAG 2.4.13: Focus Appearance (Level AAA)

Focus indicators highlight the element on a web page that is currently in focus. WCAG 2.4.13 requires that focus indicators have sufficient color contrast (at least 3:1 between the same pixels in the focused and unfocused states) and be large enough to be clearly visible. For example, when a link receives focus, an outline is displayed around the link. The color of this outline should have sufficient contrast with the background color of the page.

Ensuring focus indicators have sufficient color contrast ensures users can easily see small changes in visual appearance. This is especially beneficial for older people or keyboard users as they can easily track where they are on a page while moving around.

WCAG 2.5.7: Dragging Movements (Level AA)

Drag and drop can be cumbersome and error-prone for many people, whether they use a keyboard, have a mobility impairment, or rely on adapted input devices like head pointers or speech-controlled mouse emulators.

WCAG 2.5.7 requires that dragging movements are not the only way essential actions on a page can be accomplished, whether manipulating a slider or reordering components in a drag-and-drop interface. 

For example, a website could enable the keyboard to work with up/down/left/right arrows or provide on-screen buttons that a user could press to move a slider or sort a list. This ensures that users who struggle with or who cannot perform dragging movements can still operate within the drag-and-drop interface.

WCAG 2.5.8: Target Size (Minimum) (Level AA)

When buttons and other clickable elements are small, it’s difficult for people with hand tremors and other fine motor impairments to activate them without accidentally activating another element.

WCAG 2.5.8 requires the minimum size for all clickable elements (such as call-to-action buttons) to be at least 24 X 24 CSS pixels. It also requires websites to provide at least 24 CSS pixels of spacing between adjacent targets.

This criterion provides a Level AA alternative to WCAG 2.5.5: Target Size, a Level AAA requirement that was introduced as part of WCAG 2.1 and requires the target size for all clickable elements to be at least 44 X 44 CSS pixels.

This new capability allows individuals with fine motor limitations to easily click on buttons. It also enhances the mobile experience as users have enough spacing to select smaller buttons.

WCAG 3.2.6: Consistent Help (Level A)

If help features or help mechanisms — such as a website’s contact details or a self-help chatbot — are available on multiple pages of a website, WCAG 3.2.6 requires it to appear in the same relative place and order on each page where it appears.

For example, if a website has a ‘Chat’ option, it should appear in the lower right-hand corner of every page. Or contact details, including a phone number, hours of operation, or email address, are listed in the footer of each page. 

By consistently listing helpful information in the same place, people who may have difficulty locating help or remembering where information is listed can find it more easily.

WCAG 3.3.7: Redundant Entry (Level A)

Some forms require users to enter the same information more than once, which can be burdensome for people with motor impairments. It may also be difficult for users with cognitive disabilities as they may struggle to remember what information they’ve already inputted.

WCAG 3.3.7 requires websites to auto-populate fields or allow users to re-use previously entered data. This saves users from having to repeatedly enter information, lowers the likelihood of mistakes, and reduces the need for text entry.

WCAG 3.3.8: Accessible Authentication (Minimum) (Level AA)

The intent of WCAG 3.3.8 is to provide users with cognitive disabilities an easy, accessible way to log into websites and mobile apps. If a cognitive function test — such as memorizing a password or identifying images or characters — is used, websites must provide at least one other authentication method. 

This simplifies the authentication process for people with cognitive disabilities and allows them to authenticate based on their individual needs. One mechanism that can help with this is the use of password managers. These can help to reduce memory needs and the burden of re-typing information.

WCAG 3.3.9: Accessible Authentication (Enhanced) (Level AAA)

Similar to the criterion above, WCAG 3.3.9 is designed to simplify the login process for users with cognitive disabilities. However, this criterion goes a step further and does not permit authentication using object recognition or user-provided content, such as a picture uploaded by the user. This ensures users with cognitive issues around memory, reading (dyslexia, for example), numbers, or perception-processing limitations can log on or authenticate easily.

“This update to the Web Content Accessibility Guidelines, coupled with the Department of Justice’s recent rule on web accessibility, highlights the growing momentum behind efforts to create digital experiences that are accessible for all people.”

David Moradi, CEO of AudioEye

Steps to Ensure Your Website Meets WCAG 2.2 Standards

Even if your organization is required to meet WCAG 2.0 or 2.1 standards, it’s recommended to conform with new WCAG standards. Doing so advances the accessibility of your site and shows your commitment to providing an accessible, inclusive experience.

Below are three ways you can implement WCAG 2.2 standards in your site.

Conduct an Accessibility Audit

The first step in integrating WCAG 2.2 criteria is to do an audit of your current system. This will identify where existing accessibility issues are and give you a starting point for implementing WCAG 2.2. An Accessibility Checker like AudioEye can help with this.

Implement Changes Based on Audit Findings

Once you have the results back from the audit, start implementing the changes. We recommend starting with smaller issues — such as fixing broken links or adding alternative text to images — before tackling larger issues.

Engage Certified Accessibility Experts for Manual Testing

Automated accessibility platforms can only detect common accessibility issues. More complex issues such as poorly written alt text or low compatibility with keyboard-only or assistive technology navigation. Not only can manual testing uncover these issues, but they may also provide recommendations on how to fix these accessibility errors.

For example, AudioEye’s Digital Accessibility platform uses automated testing to uncover common accessibility issues and provides automated fixes for these issues. Anything that can’t be fixed by our automated solution is handled by our team of human testers who resolve issues through custom fixes.

A hybrid approach to accessibility testing enhances the overall accessibility of your site and creates a better, more inclusive experience.

A stylized web page with a number of accessibility errors marked by exclamation points, next to a green accessibility symbol.

How AudioEye Simplifies WCAG 2.2 Compliance

As WCAG standards continue to evolve, organizations need to continuously monitor and text their sites for accessibility errors or WCAG violations. Doing so enhances website accessibility and helps meet legal accessibility requirements.

At AudioEye, we ensure your site follows the latest WCAG standards through both automated and expert testing done by a group of accessibility experts. We also work with over 80 members of the disability community (known as the AudioEye A11iance) to perform expert custom testing of websites. Each of our testers have been trained on the latest release of WCAG standards to ensure sites meet the latest success criteria. 

The best part about working with AudioEye? There’s no need to track changes yourself — we do it for you! Our Expert Audits regularly test your site to find and fix accessibility issues before they impact your customers. 

Ready to see how compliant your website is with WCAG 2.2 standards? Schedule a free demo with AudioEye and see how we can streamline your path to accessibility.

Ready to see AudioEye in action?

Watch Demo

Ready to test your website for accessibility?

Scan your website now.

Share post

Topics:

Keep Reading