The new WCAG 2.2 Accessibility Guidelines

This article includes information about updated WCAG 2.2 Accessibility Guidelines published on the 21st of September, 2023.

This article provides the answers to the following questions:

• What is WCAG?
• Why is WCAG important?
• Who needs WCAG?
• What is WCAG POOR?
• How to meet WCAG?
• 17 criterias of the updated WCAG 2.2

The W3C Accessibility Guidelines Working Group is working on the WCAG v.3 accessibility guidelines release scheduled for the year 2024.

What is WCAG in simple words?

The WCAG is an abbreviation for Web Content Accessibility Guidelines designed to make web content more accessible to people with disabilities. The WCAG technical standards are developed by the World Wide Web Consortium (W3C) and supported by Google Lighthouse.

The WCAG Guidelines ensure equal access to information and services for people with such disabilities as: visual, auditory, physical, speech, cognitive, language, learning, and neurological disabilities.

Why is WCAG important?

The Web Content Accessibility Guidelines (WCAG) provide a standard for web content accessibility that meets the needs of individuals, organizations, and governments, avoiding claims of discrimination and legal action.

The WCAG guidelines enhance the overall user experience and usability of websites, which boosts customer satisfaction and reduces bounce rates, thus improving the website’s SEO ranking.

Who needs to be WCAG compliant?

The WCAG Guidelines were primarily designed for:

• Web content developers [such as site designers, content authors, etc.]
• Web accessibility evaluation tool developers [such as Google PageSpeed]
• Web authoring tool developers [such as WordPress, Wix, Squarespace, etc]
• As a standard for web accessibility guidelines

What does WCAG POUR stand for?

The WCAG standards have the following guidelines organized under four WCAG principles, known as POOR:

The POUR is an abbreviation for Perceivable, Operable, Understandable, and Robust.

Perceivable

• Provide text alternatives for non-text content.
• Provide captions and other alternatives for multimedia.
• Create content that can be presented in different ways, including by assistive technologies, without losing meaning.
• Make it easier for users to see and hear content.

Operable

• Make all functionality available from a keyboard.
• Give users enough time to read and use content.
• Do not use content that causes seizures or physical reactions.
• Help users navigate and find content.
• Make it easier to use inputs other than a keyboard.

Understandable

• Make text readable and understandable.
• Make content appear and operate in predictable ways.
• Help users avoid and correct mistakes.

Robust

• Maximize compatibility with current and future user tools.

How to meet WCAG?

Meeting the WCAG guidelines can seem daunting, but there are several ways to make it easier:

• Get familiar with the updated WCAG 2.2 Quick Reference Guide
  Including guidelines, success criteria, and techniques for developing and evaluating web content.
• Follow the four principles of WCAG
  The website functionality and content have to be Perceivable, Operable, Understandable, and Robust.
• Use clear and concise language
  Ensure that instructions, guidance, and error messages are clear and easy to understand.
• Ensure that non-text content is accessible
  Provide text alternatives for non-text content, such as images, videos, and audio files. This will ensure that users who cannot see or hear the content can still access the information.
• Use sufficient color contrast
  Ensure that there is sufficient contrast between text and background colors.
• Make sure the website is keyboard accessible
  Ensure that users can navigate the website using only the keyboard. This is particularly important for users with motor disabilities who may not have the fine motor skills required to operate a mouse.
• Complete one of the WCAG courses
  Learn online or take a Udermy WCAG course such as “How To Design for Accessibility” to learn more about WCAG.

New WCAG 2.2 criterias in simple words:

The updated WCAG 2.2 provides 17 additional success criteria:

1.3.4 Responsive Orientation (AA)

The website functionality and content should not be restricted to landscape or portrait display orientation.

Users with disabilities with the tablet attached to a wheelchair should be able to use the application whether it is attached to its tablet horizontally or vertically.

Benefits

• Users with dexterity impairments with a mounted device can use the content in their fixed orientation.
• Users with low vision will be able to view content in the orientation that works best for them, for example, to increase the text size by viewing the content in landscape.

1.3.5 Identify Input Purposes (AA)

The form input fields should have the expected data type identifications.

Users with disabilities should be able to autofill the forms with their personal data.

Benefits

• People with language and memory-related disabilities or disabilities that affect executive function and decision-making benefit from the browser auto-filling personal information (such as name or address) when the autocomplete attribute is used to meet this Success Criterion, which means information does not need to be remembered by the user.
• People with cerebral palsy, stroke, head injury, motor neuron disease, or learning disability sometimes prefer images for communication. They can employ assistive technology which adds icons to input fields to communicate the purpose of the fields visually.
• People with motor impairments also benefit from reducing the need for manual input when filling out forms.

1.3.6 Identify Area Purpose (AAA)

The purpose of User Interface Components, icons, and regions should have the type specified [such as ARIA landmarks].

Users with disabilities should be able to programmatically change the words in the navigation into symbols.

Benefits

Meeting this Success Criterion helps users who need extra support or a familiar interface, including the need for:

• Symbols and graphics with which users are familiar
• Fewer features and less cognitive overload
• Keyboard shortcuts

1.4.10 Content Reflow (AA)

Zoomed content should not require scrolling in two dimensions.

Users with disabilities should be able to increase the text size 400% and have the content reflowed within the width of the window, easy to read without scrolling back and forth.

Benefits

• One-column view in responsive design
  A site uses responsive design. When a person zooms in to over 300%, the layout is reflowed to one column. The user can read the content easily and does not have to scroll sideways to read.
• PDF offering reflow
  In a PDF created to conform to PDF/Universal Accessibility (ISO 14289), the content can be reflowed and zoomed in to make reading possible for someone with low vision.

1.4.11 Component Contrast (AA)

The Form Input Fields, User Interface Components, and Graphical Objects should have a contrast ratio of at least 3:1.

Users with disabilities should be able to see the form fields, buttons, icons, and other elements even in the sunlight.

Active User Interface Component Examples:

Links should have a sufficient contrast ratio and optionally underlined. The links are required to have a visible focus style.

Buttons should have a recognizable and distinguishing style [background color, optional rounder corners, centered label] with sufficient contrast.

Form Text Inputs should have a visible border [at least the bottom border] with 3:1 contrast ratio. The cursor/caret color which is displayed when the input receives focus should have a sufficient contrast ratio. White background form fields are allowed inside the dark background containers.

Toggle button’s internal background is required to have a good contrast with the external background. The round toggle within should contrast with the internal background.

Dropdown indicators in the form of down-arrows are required to understand that there is drop-down functionality in menu items and accordions.

Checkboxes should have a dark border on a white background indicating the checkbox. The black tick shape should be used to indicate the state of checked. A focus indicator is required. 

Benefits

People with low vision often have difficulty perceiving graphics that have insufficient contrast. This can be exacerbated if the person has a color vision deficiency that lowers the contrast even further. Providing a relative luminance (lightness difference) of 3:1 or greater can make these items more distinguishable when the person does not see a full range of colors.

1.4.12 Text Spacing (AA)

The content and functionality should not suffer if the user with disabilities adjusts his browser’s text style properties to:

• Line height (line spacing) to at least 1.5 times the font size;
• Spacing the following paragraphs to at least 2 times the font size;
• Letter spacing (tracking) to at least 0.12 times the font size;
• Word spacing to at least 0.16 times the font size.

Benefits

• People with low vision who require increased space between lines, words, and letters are able to read text.
• People with dyslexia may increase the space between lines, words, and letters to increase reading speed.
• Although not required by this SC, white space between blocks of text can help people with cognitive disabilities discern sections and call out boxes.

1.4.13 Content on Hover or Focus (AA)

The popup, onhover or onfocus content should be dismissible, hoverable, and persistent.
Users with disabilities should be able to interact with additional content triggered by pointer [mouse] hover or keyboard focus.

Benefits

• Users with low vision who view content under magnification will be better able to view content on hover or focus without reducing their desired magnification.
• Users who increase the size of mouse cursors via platform settings or assistive technology will be able to employ a technique to view obscured content on hover.
• Users with low vision or cognitive disabilities will have adequate time to perceive additional content appearing on hover or focus and to view the trigger content with less distraction.
• Users with low pointer accuracy will be able to more easily dismiss unintentionally triggered additional content.

2.1.4 Single Character Key Shortcuts (A)

The functionality keyboard shortcuts using single-letter, punctuation, number, or symbol characters should have the option to be disabled/ revamped / active only on focus. Users with disabilities should be able to disable the unusual application shortcuts.

Benefits

• Speech users will be able to turn off single-key shortcuts so they can avoid accidentally firing batches of them at once. This will allow speech users to make full use of programs that offer single-key shortcuts to keyboard users.
• Keyboard-only users who have dexterity challenges can also be prone to accidentally hitting keys. Those users would be able to avoid problematic single-character shortcuts by turning them off or modifying them to include at least one non-character key.
• Allowing all shortcut keys to be remapped can help users with some cognitive disabilities since the same shortcuts can be assigned to perform the same actions across different applications.

2.2.6 Timeouts (AAA)

Users should be warned of the duration of any user inactivity that could cause data loss.

Benefits

When a user knows how much time they are allowed for a task, they will know whether they can take a needed break and resume their work without needing to start again. The user can then decide if they can manage this task or not in the given time, or if they need to prepare materials in advance of starting a process. This will reduce the frustration of losing work due to a timeout.

2.3.3 Animation from Interactions (AAA)

User interaction should not trigger annoying motion animation on the page.

Users with disabilities should not be harmed or distracted by motion or motion effects.
For example, parallax scrolling and non-essential animations could cause vestibular (inner ear) disorder reactions including dizziness, nausea, and headaches.

2.5.1 Pointer Gestures (A)

The multipoint or path-based gesture functionality should be also operatable with a single pointer.

Users with disabilities should be able to zoom in and out using buttons as well as two-finger gesture movements.

Benefits

• Users who cannot (accurately) perform path-based pointer gestures – on a touchscreen, or with a mouse – will have alternative means for operating the content.
• Users who cannot perform multi-pointer gestures on a touchscreen (for instance, because they are operating the touchscreen with an alternative input such as a head pointer) will have a single-pointer alternative for operating the content.
• Users who may not understand the custom gesture interaction intended by the author will be able to rely on simple, frequently used gestures to interact. This can be especially beneficial for users with cognitive or learning disabilities.

2.5.2 Pointer Cancellation (A)

The pointer [mouse/finger] should wait until the up-event before triggering the operation on the down-event [click].

Users with disabilities should be able to move the pointer away from a mistakenly-clicked element.

Benefits

• Makes it easier for all users to recover from hitting the wrong target.
• Helps people with visual disabilities, cognitive limitations, and motor impairments by reducing the chance that a control will be accidentally activated or an action will occur unexpectedly, and also ensures that where complex controls are activated, a means of Undoing or Aborting the action is available.

2.5.3 Label in Name (A)

The components [buttons] with labels both textual and graphical should have a name parameter equal to the text that is presented visually. The button with the label “send” should not have a name parameter set to “submit”.

Users with voice recognition software should be able to focus/click the element, using its name parameter’s value. How would such a user guess that he needs to use the word “submit” instead of a visible “send” label?

Benefits

• Speech-input users can directly activate controls on a page with fewer surprising changes of focus.
• Text-to-speech users will have a better experience because the labels that they hear match the visible text labels that they see on the screen.

2.5.4 Motion Actuation (A)

Device motion [tilt/shake/rotation] functionality should have a user interface alternative.

Users with cerebral palsy or tremors should be able to disable the motion functionality and operate using other interface components [buttons, links, etc.]. The gesture navigation should have controls available to navigate.

Benefits

• This Success Criterion helps people who may be unable to perform particular motions (such as tilting, shaking, or gesturing) because the device may be mounted or users may be physically unable to perform the necessary movement. This success criterion ensures that users can still operate all functionality by other means such as touch or via assistive technologies.
• Other users will benefit in situations where they are unable to move their devices.

2.5.5 Target Size (AAA)

The size of a target [button, links, etc.] for pointed inputs [mouse/finger] should be no smaller than 44 x 44px.

Users with hand tremors or simply big fingers should be able to successfully click selected buttons and links.

Benefits

• Users who use a mobile device where touch screen is the primary mode of interaction;
• Users with mobility impairments such as hand tremors;
• Users who use a mobile device in environments where they are exposed to shaking such as public transportation;
• Users who have difficulty with fine motor movements;
• Users who access a device using one hand;
• Users with large fingers, or who are operating the device with only a part of their finger or knuckle;
• Users who have low vision may better see the target.

2.5.6 Concurrent Input Mechanisms (AAA)

The application functionality should not restrict the use of input modalities available on a platform.

Users with disabilities should be able to switch from using a keyboard, mouse, stylus, gestures, or voice.

Benefits

• Users can interact with web content with whichever input mechanism is preferred and available to them.
• Users may switch between input mechanisms when they desire or the circumstances require it.
• Users are allowed to add and remove input mechanisms at any point, where supported by the operating system.

4.1.3 Status Messages (AA)

In content implemented using markup languages, status messages can be programmatically determined through role or properties such that they can be presented to the user by assistive technologies without receiving focus.

Users who are blind or use a screen reader should hear a confirmation on submit.

Benefits

• When appropriate roles or properties are assigned to status messages, the new content is spoken by screen readers in such a way as to assist blind and low vision users. Most sighted users can observe text peripherally added to the viewport. Such content provides additional information without affecting the user’s current point of regard. The ability of an assistive technology to announce such new important text content allows more users to benefit from an awareness of the information in an equivalent manner.

The WCAG success levels

The WCAG success criteria are measured at three levels: A, AA, and AAA.

Level A is the minimum level of accessibility, and is considerate inaceptable for federal agencies, their contractors and commercial facilities.

Level AA is the mid-range level and is widely considered legally acceptable.

Level AAA is the highest level of accessibility and is the ultimate goal to strive toward.

In practice, if you wish to avoid litigation and wish to make your website accessible, aim to obtain the accessibility score of WCAG 2.2 AA.