WCAG 2.1 vs 2.0: What’s The Difference?

computer keyboard with green handicap accessible symbolIs your website accessible? WCAG 2.1 is the newest edition of the Web Content Accessibility Guidelines. You may be familiar with its predecessor, WCAG 2.0, which was released in 2008 and outlines twelve guidelines to make your website content more accessible for people with disabilities.

In April 2018, The World Wide Web Consortium (W3C), released a proposed recommendation to the WCAG 2.0 guidelines known as WCAG 2.1. This new update aims to improve accessibility guidance for users with cognitive or learning disabilities, low vision, and disabilities on mobile devices.

While WCAG 2.1 builds on the foundations of WCAG 2.0, it’s important to know the key differences between the two sets of guidelines to make sure your website is accessible to all users. Weve broken down the 17 key modifications WCAG 2.1 makes to the WCAG 2.0 framework below.

New Accessibility Guidelines WCAG 2.1 Requires:

  • Orientation: Your web content should be accessible in both portrait and landscape orientations. This aims to prevent developers from automatically setting and restricting the screen to a particular display orientation, as not all users are able to rotate their device to match.
  • Identity Input Purpose: Each input field in a form collecting information should be able to be programmatically determined by a users screen reader or assistive technology. For example, a contact form that contains fields like name,’ ‘phone number,and street addresscan be completed using autofill details stored in the users browser. This aims to assist people with language and memory related disabilities as well as motor impairments, as it reduces to need for manual input.
  • Identify Purpose: In your web content and user-interface, interface elements like input controls, navigational components, icons, and regions should be able to be programmatically determined to support comprehension and personalization. Adding semantics or metadata to components such as a link to the home page on a navigation bar provides context to users and allows them to load their own set of symbols to use. For example, for users with cognitive disabilities a link “Home” might not mean something, but a “home” icon is understood that the link will bring them back to the homepage.
  • Reflow: To assist users with low vision, web content should be able to be presented in one column when text is enlarged, so scrolling in more than one direction is not necessary. To ensure easy reading, program your web content to reflow content in one column that fits the width of the windows boundaries when the web page is zoomed in.
  • Non-Text Contrast: This requirement extends the contrast minimum requirements to non-text elements like interface components and graphical objects. These components must have a contrast ratio of 3:1 to be perceivable by people with low vision.
  • Text Spacing: Ensure users can override text spacing style properties to improve readability and comprehension. This includes line spacing, spacing following paragraphs, tracking, and word spacing. W3C has set minimum requirements for each text spacing style to ensure that text styling can be adapted by users to improve their reading experience.
  • Content on Hover or Focus: With additional content, like a pop-up menu, that appears and disappears with a pointer hover or keyboard focus, programmers must ensure all users can perceive the additional content and dismiss it without disrupting their page experience. For example, the options in a pop up menu may be obscured in magnified views. A user needs to scroll or zoom out to see the menu options in entirety, which causes the user to move their pointer and the pop-up menu disappears.
  • Character Key Shortcuts: Users must be able to turn off or reconfigure shortcuts made up of a single character key or multiple successive character keys. This assists speech input users as well as keyboard-only users who are prone to hitting wrong keys.
  • Timeouts: When a timeout is used, users must be informed what duration of inactivity will result in a page timeout and loss of data. Users must also be able to increase the timeout or add more time before the loss of date. This allows users with different cognitive disabilities to know how long they have to complete a task and extend it if necessary.
  • Animation from Interactions: Ensure users can prevent motion animation from being displayed on web pages.  For example, a cog turning animation while a new web page is being loaded should be able to be turned off.
  • Pointer Gestures: All functionality should be able to be operated with a single pointer. Multipoint or path-based gestures are too complex for some users and prevents them from interacting with content.
  • Pointer Cancellation: For users who may inadvertently initiate mouse events, pointer actions must be configured to allow users to cancel pointer operations.
  • Label in Name: The accessible name of user interface components with labels should contain the text that is being presented visually to assist those who rely on visible labels. For example, a Learn More” button begins with the same text as the visible label.
  • Motion Actuation: Any function that is triggered by moving a device or by gesturing towards the device must be also have the option to be operated through interface components. For example, instead of shaking a device to undo, a user can tap button.
  • Target Size: This requirement ensures pointers are large enough to bee seen and used on all devices by requiring them to be at least 44 by 44 CSS pixels.
  • Concurrent Input Mechanisms: Your web content should allow people to use and switch between different input modalities. For example, a user opens a menu with the keyboard, and then navigates between the menu items with speech recognition.
  • Status Messages: Status messages should be able to be programmatically determined to be presented to users by their own assistive technologies.

For more information on these specific modifications and making your website WCAG 2.1 accessible, be sure to check out the full set of guidelines on W3C’s website.

Need help making your website WCAG 2.1 accessible? Our team of programmers is passionate about making your website accessible to all.

Give us a call today at 518-743-9424 or contact us online to get the conversation started!