Skip to main content

WCAG 2.0 and 2.1 – What is the difference?

26 May, 2020 by Anurag

a man standing facing laptop monitors

Yes, there are few changes that have been made in Web Content Accessibility Guideline (WCAG) 2.1 if we compare it with the WCAG 2.0. Web Content Accessibility Guidelines (WCAG) explains how to make web content accessible for people with disabilities which includes diverse user groups. 

WCAG Timeline 

 WCAG 2.0 was published in 2008 and after 10 years WCAG 2.1 was published in 2018. WCAG 2.1 is not a replacement of WCAG 2.0 but is an extension of WCAG 2.0 with additional success criteria included to cater the needs of different user groups. In WCAG 2.1 there are 17 new success criteria’s included across all the 3 conformance levels. Out of the 17 new success criteria’s: 

  • 5 at Level A 
  • 7 at Level AA 
  • 5 at Level AAA 

The new success criteria’s included in WCAG 2.1 aims at making the web content more accessible for: 

  • Mobile users 
  • Low vision users 
  • Cognitive and learning impaired users  
  • Users with motor and visual impairments 

A new guideline has also been introduced in WCAG 2.1 to make it a total of 13 guidelines. The newly added guideline is 2.5 Make it easier to use inputs other than keyboard.” 

Let us now find out what all has been included in WCAG 2.1! 

  • Orientation: As per success criteria 1.3.4 Level AA content and functionality should be available irrespective of user’s device orientation. This requirement was included to cater to the needs of mobile device users, users with mobility impairments and those with low vision.  
  • Identify input purpose: As per success criteria 1.3.5 Level AA, forms that collect user data should define the purpose of input fields programmatically. This requirement was included to enable users with cognitive and learning impairments as well as those with motor impairments fill up forms easily. 
  • Reflow: As per success criteria 1.4.10 Level AA, all the page content and functionality should be available without requiring users to scroll in 2 dimensions. This requirement was included to make it easier for users with low vision to read and interact with the content without having to scroll horizontally. Reflow also helps to ensure that content is available for mobile device users. 
  • Non text contrast: As per success criteria 1.4.11 Level AA, a contrast of 3:1 against the adjacent colors should be present for user interface control state (i.e. hover, focus etc.) and key images (i.e. diagrams, graphs, informative icons etc.). This requirement was included to help low vision users identify user interface components as well as read the information displayed using images with ease. In WCAG 2.0 contrast requirement was present for text and in WCAG 2.1 it has been extended to include non-text content as well. 
  • Text spacing: As per success criteria 1.4.12, content and functionality should not be lost when text spacing styles are applied. This requirement was added to cater to the needs of low vision users, dyslexic users, and users with cognitive impairments to help them read the web content with ease.  
  • Content on Hover or Focus: As per success criteria 1.4.13 Level AA, content that becomes available on hover or focus should be  
  • Dismissible: Content should be dismissible without user having to lose their current position. This will enable users to continue reading the web content. 
  • Hoverable and focusable: Content available on hover or focus should be hoverable and focusable itself to help low vision users read the content at high magnification levels.  
  • Persistent: Content should not disappear unless users dismiss it. This will provide low vision users and users with learning impairments with more time to read the content.  
  • Character key shortcuts: As per success criteria 2.1.4 Level A, web pages should not include single character key shortcuts for carrying out different tasks. This requirement was included to ensure that speech input users don’t end up activating user interface controls while giving voice commands and to make sure that users with dexterity impairments who rely on keyboard interaction might not accidentally activate user interface controls when they unintentionally press a key.  
  • Pointer gestures: As per success criteria 2.5.1 Level A, All the functionality of a web page that involves multipoint gestures or path-based gestures should provide users with an alternate means to carry out the task using single point activation controls. This requirement was included to ensure that users with motor impairments and users with cognitive and learning impairments can carry out the complex gestures through an alternate method.  
  • Pointer cancellation: As per success criteria 2.5.2 Level A, all the page functionality should be executed on the Up event and not on Down event. If any functionality is executed on Down event, provide users with a mechanism to cancel it. This requirement was included to help users with visual, motor and learning impairments who might get disoriented by a control getting activated unexpectedly on Down event.  
  • Label in Name: As per success criteria 2.5.3 Level A, accessible name of a user interface control contains text that is present in the visual label. This requirement was included to help speech input users navigate to and activate user interface controls based on their visual labels and not getting surprised with focus moving to unexpected location on the page when they give voice commands.  
  • Motion actuation: As per success criteria 2.5.4 Level A, all the web page functionality that can be activated with device or user motion can also be activated with user interface control. This requirement was included to make sure that users with motor impairments can interact with all the page functionality.  
  • Status messages: As per success criteria 4.1.3 Level AA, status messages can be defined programmatically to ensure that assistive technologies can render them without the status messages receiving focus. This requirement was primarily included for users of screen readers who often go unaware about onscreen changes that happen dynamically after they interact with different user interface controls.  

Are you looking to get your website or application reviewed for WCAG 2.1 conformance? Reach out to us at sales@barrierbreak.com. 

Comments

Not yet commented

Leave a reply

This field is required.
This field is required.
This field is required.