Understanding the WCAG 2.1 Guidelines/Requirements

WCAG 2.1 compliance
WCAG 2.1 was created to improve accessibility guidance for three key user groups: those with cognitive or learning disabilities, individuals with low vision, and users on mobile devices. Various approaches were considered and refined by the Working Group to meet these needs. The final set of success criteria was determined based on factors such as the structure inherited from WCAG 2.0, the clarity of proposals, and project timelines. While WCAG 2.1 represents progress in providing accessibility guidance, it’s important to acknowledge that these guidelines may not address all user needs comprehensively. Additionally, WCAG 2.1 maintains compatibility with WCAG 2.0, meaning that conforming to WCAG 2.1 also ensures compliance with WCAG 2.0 standards. In this article, we’ll explore the details of WCAG 2.1 to better understand its implementation and significance.  

WCAG 2.1 Checklist – WCAG 2.0 vs 2.1

WCAG 2.1 expands upon WCAG 2.0 by introducing new success criteria, definitions, guidelines for organization, and additional sections. This approach helps clarify that websites meeting WCAG 2.1 standards also fulfill WCAG 2.0 requirements, ensuring compliance with specific obligations outlined in WCAG 2.0. The Accessibility Guidelines Working Group suggests adopting WCAG 2.1 as the primary conformance target for websites to improve accessibility and prepare for future policy changes.

Read More on: Understanding WCAG 2.0 Requirements


New Success Criteria in WCAG 2.1

WCAG 2.1 introduces several new Success Criteria, including:  

1.3.4 Orientation (Level AA)

Ensures that content remains usable across various display orientations, avoiding limitations to specific formats such as portrait or landscape unless necessary.  

1.3.5 Identify Input Purpose (Level AA)

Requires that input fields collecting user information have identifiable purposes, improving accessibility for users interacting with form input data.  

1.3.6 Identify Purpose (Level AAA)

Mandates that the purpose of user interface components, icons, and regions can be determined programmatically, ensuring comprehensive accessibility standards in content implemented using markup languages.  

1.4.10 Reflow (Level AA)

Content should be presented so that it doesn’t lose any information or function and doesn’t require scrolling in two directions. Here’s how it works:
  • For vertical scrolling content, it should fit into a space that’s 320 CSS pixels wide without needing to scroll up and down.
  • For horizontal scrolling content, it should fit into a space that’s 256 CSS pixels tall without needing to scroll side to side.
However, there are some exceptions. If parts of the content need a two-dimensional layout for use or understanding, then scrolling in both directions might be necessary.  

1.4.11 Non-Text Contrast (Level AA)

When it comes to visual presentation, certain elements need to stand out from their surroundings. Here’s what’s required:
  • User Interface Components: The visual appearance of things like buttons and menus should have enough contrast against the background (at least 3:1 ratio) so they’re easy to see and understand. This rule applies except for cases where components are inactive or where the appearance is controlled by the user agent.
  • Graphical Objects: Graphics that are essential for understanding the content should also have good contrast. Again, a 3:1 ratio against the background is required, unless the presentation of the graphics is crucial to the information they convey.

1.4.12 Text Spacing (Level AA)

When text is formatted using certain style properties, it shouldn’t lose any content or functionality. Here’s what’s needed:
  • Line height (spacing between lines) should be at least 1.5 times the font size.
  • Spacing after paragraphs should be at least twice the font size.
  • Increase letter-spacing (tracking) for better readability. Aim for at least 0.12 times the font size.
  • Enhance word spacing for better clarity. The recommended minimum is 0.16 times the font size.
There’s an exception: If a language or script doesn’t use one or more of these style properties, it can still meet the requirements using only the properties relevant to that language or script.  

1.4.13 Content on Hover or Focus (Level AA)

When hovering over or focusing on an element causes additional content to appear and disappear, consider the following:
  • Dismissable: Ensure there’s a way to close the extra content without moving the pointer or changing focus unless it’s needed to correct an input error or doesn’t block other content;
  • Hoverable: If hovering over the element reveals extra content, it should stay visible while the pointer is on it;
  • Persistent: Keep the extra content visible until the hover or focus action ends, the user closes it, or the information becomes outdated.
  • Exception: The appearance of the extra content is controlled by the user agent and can’t be changed by the content creator.

2.1.4 Character Key Shortcuts (Level A)

If content uses keyboard shortcuts with letters, punctuation, numbers, or symbols only, make sure one of these applies:
  • Turn off: Provide a way to disable the shortcut;
  • Remap: Allow users to change the shortcut to include non-printable keys like Ctrl or Alt;
  • Active only on focus: Make sure the shortcut only works when the element has focus.

2.2.6 Timeouts (Level AAA)

Warn users about potential data loss due to inactivity unless the data is saved for more than 20 hours without user interaction.  

2.3.3 Animation from Interactions (Level AAA)

Consider turning off animations triggered by user actions unless they’re essential for functionality or conveying information.  

2.5.1 Pointer Gestures (A)

When using gestures that involve multiple points or paths for operation, it should be possible to operate them with just one pointer without needing a path-based gesture, unless a multi-point or path-based gesture is absolutely necessary.  

2.5.2 Pointer Cancellation (Level A)

When a function can be carried out using a single pointer, at least one of the following conditions must be met:
  • No Down-Event: The down-event of the pointer is not used to execute any part of the function.
  • Abort or Undo: The function completes upon the up-event, and there is a way to cancel the function before completion or undo it afterward.
  • Up Reversal: The up-event undoes any actions initiated by the preceding down-event.
  • Essential: Completing the function upon the down-event is indispensable.

2.5.3 Label in Name (Level A)

For user interface components with labels containing text or images of text, the name should include the text presented visually.  

2.5.4 Motion Actuation (A)

Features that respond to device or user motion should have options to turn off this function to prevent unintended actions. However, there are exceptions:
  • Supported Interface: If motion is used for accessibility purposes through a supported interface.
  • Essential Functionality: When motion is essential to the function and disabling it would hinder the activity.

2.5.5 Target Size (AAA)

Clickable targets for pointer inputs should be at least 44 by 44 CSS pixels, except:
  • Equivalent Link: If there’s a link or control on the same page that meets the size requirement.
  • Inline Target: The target is within a sentence or block of text.
  • User Agent Control: The size is determined by the user agent, not the content author.
  • Essential Presentation: A specific appearance of the target is crucial for conveying information.

2.5.6 Concurrent Input Mechanisms (Level AAA)

Web content should allow the use of various input methods available on a platform, unless:
  • Essential Restriction: Limiting input methods is necessary for security reasons or user preferences.

4.1.3 Status Messages (Level AA)

In web content using markup languages, status messages should be identifiable for assistive technologies without requiring user focus.  

Closing Thoughts

WCAG 2.1 is a great step towards making the web more user-friendly for everyone. It tackles challenges faced by people with sight issues, those who learn differently, and mobile device users. While it might not cover every situation, WCAG 2.1 gives website creators helpful tools to build a more inclusive web world. Following these guidelines and keeping an eye on future updates will help ensure everyone can enjoy the web, no matter their background or ability.
Continue Reading: Understanding WCAG 2.2 Requirements

Get AI-Driven Accessibility Solutions

Empower your organization with scalable, cost-effective, and efficient tools for an inclusive user experience.


Debangku Sarma

Digital Marketing Associate
Continual Engine

Vijayshree Vethantham

Senior Vice-President, Growth & Strategy
Continual Engine US LLC

Do You Need Some Help? Don't Worry, We've Got You!

"*" indicates required fields

Step 1 of 3

What is your goal?*
Skip to content