Web Content Accessibility Guidelines (WCAG) 2.2

A Comprehensive Guide To WCAG 2.2

Today, making web content more accessible to people with disabilities is more important than ever. The Web Content Accessibility Guidelines (WCAG) 2.2 provide standards for web designers and developers to improve the accessibility of their web content.

These guidelines cover a wide range of accessibility issues, from providing alternative text for images to designing pages that work well with assistive technologies, such as screen readers.

Also, compliance with Web Content Accessibility Guidelines standards can improve the usability of your site for all users, not just those with disabilities.

Making your site accessible to those with auditory, visual, physical, or cognitive disabilities is an integral part of a responsive web design. Fortunately, the WCAG 2.2 guidelines provide a clear framework for achieving this goal.

What Is WCAG 2.2?

WCAG 2.2 is the second major revision of the Web Content Accessibility Guidelines. The guidelines are developed by the World Wide Web Consortium (W3C) – the main international standards organization for the internet.

This update to the guidelines includes several new success criteria, which are recommendations for making web content more accessible. The new success criteria cover a wide range of accessibility issues, including providing captions for audio content and designing forms that are easier to use for people with cognitive disabilities.

WCAG 2.2 is built through the W3C in collaboration with individuals and organizations around the world. Their aim is to build a robust framework that organizations of all sizes can use to improve the accessibility of their website content and design.

Basically, WCAG 2.2’s goal is to address the cognitive, learning disabilities, language, and testability issues in the previous versions. It provides new and updated success criteria, as well as adds guidance on how to test web content for compliance with the guidelines.

Human evaluation and automated testing assess whether website content meets the success criteria. However, content isn’t the only factor that contributes to web accessibility. Accessible web browsers and authoring tools are also important.

Why These Guidelines Change

There are many reasons why the Web Content Accessibility Guidelines (WCAG) require regular updates. These include:

The Evolution of Technology

When Web Content Accessibility Guidelines was first published in 2008, the web was a very different place than it is now. Technologies have changed and evolved, which has led to changes in how people use and access the web.

For example, these days, people use a wider range of devices to access the internet than ever before. This includes everything from smartphones and tablets to gaming consoles, smart TVs, and other mobile devices. As a result, the way people interact with web content has also changed.

To keep up with these changes, WCAG needs to be updated on a regular basis.

The Need for International Standards

As the internet has become more globalized, there is a greater need for international standards. This is especially true when it comes to web accessibility.

Web Content Accessibility Guidelines WCAG provide a set of guidelines that all types of organizations and businesses around the world can use to make their websites and content more accessible. Having these guidelines makes it easier for website owners to know what they need to do to make their websites accessible to everyone.

Changes in the Law

There have also been changes in the law that affect web accessibility and WCAG. For example, the European Union has passed a number of laws that require websites to meet certain accessibility standards. As a result, WCAG has to be updated with new success criteria and guidelines to reflect these changes in the law.

Changes in User Needs

Finally, the needs of users have also changed over time. As more people with disabilities start using the internet, there is a greater need for websites to be accessible to them.

The Web Content Accessibility Guidelines is the most comprehensive set of guidelines for making website content accessible. It covers a wide range of topics, from text to images to videos.

By following these guidelines, organizations can make their websites more accessible to a wider range of users.

WCAG 2.2: The 4 Layers Of Guidance

There are four different parts to the WCAG 2.2. These include the Principles, Guidelines, Success Criteria, and Sufficient and Advisory Techniques.

Principles

WCAG 2.2 is based on the following four principles. These provide the foundation for web accessibility.

Perceivable

The information on the web should be presented in a way that users can perceive it. This means that users should be able to see, hear, and touch the information on the web.

Operable

The interface of the web should be easy to use for all users. This means that users should be able to navigate, interact, and understand the information on the web.

Understandable

The information on the web should be easy to understand for all users. This means that users should be able to read, write, and speak the information on the web.

Robust

The web should be able to work with a variety of technologies. This means that users should be able to access the information on the web using a variety of technologies.

General Web Accessibility Guidelines

There are many guidelines in WCAG 2.2, but some of the most important ones are:

Clear and Simple Language

The text on the web should be easy to read and understand.

Easy Website Navigable

The website should be easy to navigate, and users should be able to find the information they are looking for.

Colour

The colours on the website should be easy to see, and they should not interfere with the ability of users to see the information on the web.

Assistive Technology

Assistive technology should be able to read the site and be used easily. These include screen readers, screen magnifiers, text-to-speech software, speech recognition software, and alternative keyboards or pointing devices.

Captions and Transcripts

Videos on the web should have captions and transcripts should be available for all audio content.

Page Break Locators

Page break locators are essential in helping people with disabilities know where web pages end. Use a specific page break locator for every web page and you will help users with different abilities to easily access your site.

Navigation Without a Mouse

The website should be navigable without the use of a mouse. It should also have a clear and logical structure so that users can easily find the information they are looking for.

Alternative Text

Images on the web should have alternative text so that users can understand the content of the images should they be unable to see them. There are many authoring tools that can help you achieve this.

Headings and Labels

The website should use headings and labels to help users navigate the website and to understand the content on the web.

Audio Descriptions

Videos on the web should have an audio description so that users who are blind or have low vision can understand the digital content of the video.

Error Messages

When there is an error on the website, an error message should be displayed to help users understand what went wrong.

Valid Code

The code on the web page should be valid so that it can be used by a variety of browsers and devices.

Web Accessibility Success Criteria

Each guideline has a number of success criteria that help web developers create websites that meet the needs of all users. The success criteria are divided into three levels:

Level A

This success criteria level is the most basic level of digital accessibility. All websites should meet this level. It includes criteria that are necessary for some users to be able to use the website.

Level AA

This is the level that most organizations should meet. It is also the level required by many government agencies.

Level AAA

This is the highest level of conformance. Very few sites will be able to meet all Level AAA Success Criteria, due to the demands they place on both users and authors. You need to invest time, effort, and resources to reach the Level AAA conformance.

Techniques

WCAG 2.2 details a wide range of techniques that site owners can use to create accessible content. Some are specific to particular technologies, while others are general in nature and can be applied across technologies.

The techniques fall into three distinct categories as outlined below:

Sufficient Techniques

These are the techniques that you must use in order to meet the Success Criteria. If there is more than one sufficient technique for a Success Criterion, then you can choose any one of the techniques to implement.

Advisory Techniques

Advisory Techniques are informative only and do not directly impact the conformance of web content to WCAG. They are generally used as guidance to understand how website owners can meet the Success Criteria in WCAG or to offer information about digital accessibility features that may not be obvious from the Success Criteria themselves.

Failure Techniques

The Failure Techniques are used to determine if the content fails WCAG. If any of the Failure Techniques apply, then it means that the website does not meet the Success Criteria for web accessibility.

WCAG 2.2 vs WCAG 2.1

WCAG 2.2 is an improved version of WCAG 2.1. This new version has been made to continue the good work of promoting digital accessibility for people with disabilities. With it, users with low vision, cognitive or learning disabilities, deafness or hearing loss, and physical disabilities will have an easier time accessing the web.

WCAG 2.2 is developed on and is backward compatible with WCAG 2.1. This means that if something is accessible under WCAG 2.1, it will also be accessible under WCAG 2.2.

What’s New With WCAG 2.2?

As mentioned, there are three levels of conformance with WCAG: A, AA, and AAA. The main difference between WCAG versions is the addition of new Success Criteria at each level.

The Accessibility Guidelines Working Group advises that sites adopt the new WCAG 2.2 since it has been designed to be more user-friendly.

If you have not done so already, now is a good time to start thinking about how you can make your site WCAG compliant with the new Success Criteria.

The New Success Criteria

The WCAG 2.2 comes with nine new success criteria. We outline these below:

Success Criteria 2.4.11, “Focus Appearance (Minimum)”

Success Criteria 2.4.11 is a Level AA Success Criterion. It outlines the requirements for focus indicators for user interface components when they receive keyboard focus. A focus indicator is a small graphical cue that shows which element on the page has focus. It includes things like the dotted outline around a form field when it is selected or a clearly visible cursor to help someone navigate a webpage.

Basically, when an element receives focus, it must be visually distinguishable from other elements with a clear border.

According to the web accessibility guidelines, the focus indicator needs to have a minimum contrast ratio of 3:1 between focused and unfocused states.

The WCAG working group felt that there were many cases where this was not being met and so they added this success criterion.

Focus appearance is something that many website owners overlook but is important for all users, especially those using screen readers or other assistive technologies. This Success Criterion will help to make sure that all elements are distinguishable when they receive focus.

It is primarily for people who use screen magnifiers, but it also benefits people who have low vision and use high-contrast mode or those who have difficulty distinguishing colors.

Success Criteria 2.4.12, “Focus Appearance (Enhanced)”

This is a Level AAA Success Criterion and is similar to the previous one, but with a few additional requirements. The main difference is that, in addition to the element being distinguishable when it receives focus, it must also be visually distinguishable when it does not have focus.

For your site to pass the 2.4.12 Success Criterion, the contrast ratio must be at least 4.5:1 between colors. Also, the contrasting area should be at least two times the area of a 1 CSS pixel perimeter of the unfocused element. This means that the minimum size for an unfocused element would be 24x24px.

This Success Criterion is important for people who have low vision and use high-contrast mode or those who have difficulty distinguishing colors.

Success Criteria 2.4.13, “Fixed Reference Points”

This is a Level A Success Criterion that addresses the need for website content to be presented in a way that is not solely dependent on visual cues. When people with low vision zoom in on content, they can lose their place if there are no fixed reference points.

To address this, websites can provide landmarks or headings, or by using an HTML layout that uses position. Also, you can make sure that navigational elements are repeated at the top of each page.

For example, if you are writing an eBook, you could use headings and landmarks to help people with low vision keep their place. You could also use a layout that keeps the navigation elements in the same spot on each page so that people can easily find them.

Make sure users can navigate to a particular page or resource through a clickable table of contents or by search.

If you are using a drag-and-drop interface, make sure that there are fixed reference points so that people can easily see where they are in the content.

This is an important Success Criterion for people with low vision, but it is also important for people who are blind and use screen readers. When people zoom in on content, the screen reader can lose its place. This is especially true if the content is long.

It’s worth noting that there is a digital format that meets this WCAG 2.2 requirement by default. For instance, PDFs have fixed reference points. So, if you are using PDFs, you don’t need to do anything else to meet this Success Criteria 2.4.13.

Success Criteria 2.5.7, “Dragging Movements”

Success Criteria 2.5.7 is a Level AA criterion in WCAG 2.2. It requires that users be able to complete a dragging movement using a single pointer, without having to hold down a modifier key. If possible, doing away with a dragging operation altogether is the best solution. But if you must have one, make sure it can be completed using a single pointer.

This is important for people with hand impairments and other fine motor problems who may have difficulty holding down more than one key at once.

According to WCAG 2.2, webmasters need to provide users with an alternative to dragging that doesn’t require the use of a modifier key. This includes using speech-controlled mouse emulators, keyboard-only navigation, and other natural keyboard controls.

Success Criteria 2.5.8, “Pointer Target Spacing”

This is a level AA criterion that requires the target space of every single pointer to be at least 44 by 44 CSS pixels. This means that, at the default font size, there should be four characters horizontally and four lines vertically between targets. This is to prevent the inadvertent selection of targets that are close together, especially when using a touch screen or trackpad.

There are a few exceptions to Success Criteria 2.5.8. These include instances where:

• The target is a link or control that has already been selected, focused on, hovered over, or otherwise indicated as being active.
• The target is inline a sentence.
• The spacing for information is not a target minimum size.

This criterion is important for people with fine motor impairments who may have difficulty precisely targeting small areas on a screen. It is also important for people with cognitive impairments who may have difficulty understanding why they are selecting a particular target if the targets are too close together.

How To Meet This Criterion

• Increase the size of targets. This is probably the easiest way to meet the criterion, especially if you have a lot of small targets on your page.
• Reduce the amount of space between targets. If you have a lot of targets that are close together, you can try reducing the amount of space between them.
• Increase the contrast between targets and the surrounding content. This will make it easier for people with visual impairments to see your targets.
• Use a different pointer style for your targets. The WCAG guidelines suggest using a closed hand single pointer style for targets that are close together.
• Make your targets touch-friendly. If you are targeting mobile devices, make sure that your targets are large enough to be touched easily.
• Add a border around your targets. Doing this will make your targets easier to see and will also help people with visual impairments to see them.
• Use a different color for targets. The WCAG 2.2 guidelines suggest using a color that has good contrast with the surrounding content. This will make your targets easier to see for people with visual impairments.
• Add labels to targets. This will help people with cognitive impairments to understand what they are selecting.
• Use icons instead of text. This can be helpful for people with cognitive impairments who may have difficulty understanding the text.

The main purpose of Success Criteria 2.5.8 is to ensure people can choose targets with speech-controlled mouse emulators or fingers without accidentally selecting the wrong thing. This is especially important on touch screens and mobile devices, where it can be easy to select the wrong target if they are too close together.

Success Criteria 3.2.6, “Consistent Help”

This Level A criterion requires website owners to provide users with the ability to find help content when they need it, without having to go through complex navigation.

Sites must offer clear access to the following:

• human contact details
• human contact mechanism
• self-help functionality
• a fully automated contact mechanism

Websites with contact pages automatically pass this criterion, as long as you can find the contact page using the site’s search functionality or by following a page link from the home page.

Likewise, if a website has an FAQ section, that would also be considered sufficient help content for the purposes of this criterion.

To pass this criterion, websites must provide one of the following:

• A search function: This can be a simple search bar on the homepage or a more robust search functionality that includes an index, search results pages, and the ability to filter and sort results. Make sure there are no hidden controls that prevent users from accessing the search function.
• Links to supporting documents: These links can be included in the header or footer of the site, or embedded within individual web pages as needed. The important thing is that they are easily accessible from anywhere on the site.
• Contact information: This can be a simple email address or phone number, or a more robust contact page with multiple methods of communication.

If you want to go above and beyond in terms of providing helpful content, you could also consider implementing a live chat feature or a customer support forum. However, these are not required in order to pass the success criterion.

There are a few different ways to implement search functionality on your website. The most important thing is that the search bar is easily visible and accessible from anywhere on the site.

One common method is to include the search bar in the header, along with the logo and main navigation menu.

Another option is to have a separate search results page that is accessible from the Home Page. This web page would include an index of all the web pages on the site, as well as the ability to filter and sort results.

Success Criteria 3.2.7, “Visible Controls”

Success Criteria 3.2.7 is a Level AA criterion that is all about making sure that user interface components, such as forms, text fields, and buttons, are visible to everyone.

It is important because people who use screen readers or other assistive technologies need to be able to see these controls in order to interact with them.

There are several ways to make sure that user input controls are visible. First, make sure that the contrast ratio between the foreground and background colors of the components is at least four to one.

You can also use a CSS property called ‘outline’ to draw a line around the component. This is especially helpful if the component is inside of a container with a background image.

Another way to make sure that user interface components are visible is to use the ‘aria-label’ attribute. This attribute allows you to provide a label for the component that will be read aloud by screen readers.

Success Criteria 3.3.7, “Accessible Authentication”

This Level AA criterion requires websites to provide alternative logging-in methods.

When you visit most sites, they often have some form of cognitive test you need to perform, such as a CAPTCHA, a mathematical problem to solve, or a distorted word to read to prove “you are not a robot”. These kinds of tests might be a problem for people with cognitive disabilities.

So, Success Criteria 3.3.7 recommends providing alternative authentication methods to cognitive tests. This may be accomplished by providing an accessible alternative to the CAPTCHA or other cognitive function test used.

If the CAPTCHA or other cognitive test is not accessible for everyone to complete, then some users may not be able to authenticate themselves and access the content they need.

There are a number of ways to make these types of authentication tests more accessible:

• Use an audio CAPTCHA instead of a visual one
• Allow the user to choose from a set of options, including an audio option
• Provide an accessible alternative to the CAPTCHA, such as a link to an email address or phone number where the user can request assistance

This new Success Criterion is primarily for users who are not able to see or hear. However, it may also benefit users with cognitive disabilities who have difficulty understanding this type of cognitive function test and other complex authentication mechanisms.

Success Criteria 3.3.8, “Redundant Entry”

Success Criteria 3.3.8 aims to simplify website forms and make it easier for people with disabilities, as well as those without, to submit their information online.

For example, when you need to fill in shipping or billing details, the process can be time-consuming and tedious. Some people may have trouble doing this so it takes a lot of effort and can be frustrating to do.

So, when a website visitor has typed their information in once, Success Criteria 3.3.8 requires websites to have the option to then auto-populate the fields with the previously given information or have it available for the user to select.

This criterion will reduce redundant data entry for users who need to input the same data into forms more than once in a session.

There are three exceptions to this criterion. Information doesn’t need to be auto-populated or visible to select when:

• inputting the information is essential (meaning that if it were removed, it would change the functionality of the information or content)
• the information is necessary to ensure security
• previously information isn’t valid anymore

What Are The Changes For Websites?

The Success Criteria above fall under four general guidelines in WCAG 2.2 for making websites more accessible to people with disabilities. These guidelines are outlined below:

Guideline 2.4 Navigable

This is a guideline that has been in place in previous WCAG versions. In WCAG 2.2, however, it is being promoted from Level A to Level AA.

“Navigable” means that users should be able to easily navigate around your website. This includes being able to find their way back to the Home Page, using headings and lists, and being able to use the search function.

Ensure you provide clear and consistent navigation throughout your website. This will make it easier for users with disabilities to find their way around.

You can do this by using consistent headings and layouts throughout your website. You should also use lists (ordered or unordered) to break up text and make it easier to read.

If you have a search function on your website, make sure that it is easy to use and that the results are relevant to the user’s query.

Guideline 2.5 Input Modalities

This new guideline in WCAG 2.2 requires that content can be operated using a variety of input methods beyond keyboards, such as voice, switches, and touch. This is in addition to the existing requirement for full keyboard accessibility.

The aim is to make it possible for as many people as possible to use web content, regardless of their disability or impairment.

Also, by making content accessible using a variety of input methods, it becomes more usable for everyone, not just those with disabilities.

Achieving this guideline will require some changes to how content is authored, and may also require the use of new technologies. However, the benefits of accessible content should outweigh any costs involved.

Guideline 3.2 Predictable

The WCAG 2.2 guidelines stipulate that web content should be presented in a way that is predictable. This means that users should be able to predict what will happen when they interact with web content.

For example, if a user clicks on a link, they should know where that link will take them.

This guideline also includes the concept of consistent navigation. This means that users should be able to easily find their way around a website.

The navigation should be consistent and logical from one page to the next, and users should be able to easily return to the Home Page or any other page on the site.

Guideline 3.3 Input Assistance

Forcing users to enter information in a certain format can be frustrating and may cause them to abandon your site altogether.

Whether on computers or mobile devices, input fields should have clear labels that describe the expected data.

If additional guidance is needed, such as examples or formatting instructions, it should be provided nearby the field.

When users have to select an item from a list, the list should be provided in a logical and intuitive order. If the list is long, consider providing a search feature or a way to filter the results.

If an input field requires a specific format, such as a date or phone number, provide clear instructions on how to format the data. Consider using client-side validation to give users feedback as they enter information into the field.

When users make a mistake on a form, they should be able to easily correct it. Error messages should be specific and helpful, and they should be displayed near the relevant field. All required fields should be clearly marked so that users know which ones they need to complete before they can submit the form.

By following these guidelines, you can make sure that your forms are accessible to all users, regardless of their disability.