What’s new with the Web Accessibility Guidelines WCAG 2.1

W3C, the World Wide Web consortium, created in 1999 the first version of WCAG [w’kæg], the Web Content Accessibility Guidelines, in order to make online content accessible to all (i.e including people with disabilities). W3C defines disability as follows: “Blindness and low vision, deafness and hearing loss, learning disabilities, cognitive limitations, limited movement, speech disabilities, photosensitivity and combinations of these.”

 

While WCAG 1.0 mainly focused on HTML, WCAG 2.0 (2008) takes into account all of the digital content (PDF, etc.) and adds the four principles that are now used to break down accessibility: Perceivable, Operable, Understandable and Robust (POUR). Ten years later, with WCAG 2.1 as an addition to WCAG 2.0, the guidelines now also focus on mobile accessibility, accessibility for people with low vision and people with cognitive and learning disabilities.

 

Learn more about the 17 new success criteria below:

 

1.3 Adaptable

  • 1.3.4 Orientation (AA)

“Create content that can be presented in different ways (for example simpler layout) without losing information or structure.” Users should be able to use the website in portrait or landscape as they may not be able to turn their devices.

 

  • 1.3.5 Identify Input Purpose (AA)

“The purpose of each input field collecting information about the user should be programmatically determined”. If the input fields are clearly defined in the source code, browsers should fill them with the users’ information, which can be helpful.

 

  • 1.3.6 Identify Purpose (AAA)

“In content implemented using markup languages, the purpose of user interface components, icons, and regions can be programmatically determined.” The idea is the same as before but applied to all elements that can (and thus, should) be defined. The more the elements are defined, the more screen readers and other pieces of assistive technology will be able to identify them and give them meaning.

 

1.4 Distinguishable
“Make it easier for users to see and hear content including separating foreground from background.”

  • 1.4.10 Reflow (AA)

“Content can be presented without loss of information or functionality, and without requiring scrolling”.

 

  • 1.4.11 Non-Text Contrast (AA)

“The visual presentation of user interface components and graphical objects have a contrast ratio  of at least 3:1 against adjacent color(s).”

 

  • 1.4.12 Text Spacing (AA)

 

Recommended text spacing:

 

“Line height (line spacing) to at least 1.5 times the font size;

Spacing 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.”

 

This should allow people with dyslexia and low vision to read the texts better.

 

  • 1.4.13 Content on Hover or Focus (AA)

This rule is about how to implement additional content that is triggered if the pointer hovers an element. This new content shouldn’t get in the way and should stay on screen long enough to be read.

 

2.1 Keyboard Accessible

  • 2.1.4 Character Key Shortcuts (A)

Users should have the possibility to deactivate or reprogram keyboard shortcuts.

 

2.2 Enough Time

“Provide users enough time to read and use content.”

 

  • 2.2.6 Timeouts (AAA)

“Users are warned of the duration of any user inactivity that could cause data loss, unless the data is preserved for more than 20 hours when the user does not take any actions.”

 

2.3 Seizures and Physical Reactions

“Do not design content in a way that is known to cause seizures or physical reactions.”

 

  • 2.3.3 Animation from Interactions (AAA)

“Motion animation triggered by interaction can be disabled, unless the animation is essential to the functionality or the information being conveyed.”

 

The W3C webpage provides a false testimony that makes this success criterion clearer: “In the online tax app, as I move my mouse around or tab to different fields, this little bubble with the current balance follows me around the screen. Makes me dizzy and nauseous.

 

2.5 Input Modalities

“Make it easier for users to operate functionality through various inputs beyond keyboard.”

 

  • 2.5.1 Pointer Gestures (A)

“All functionality that uses multipoint or path-based gestures for operation can be operated with a single pointer without a path-based gesture, unless a multipoint or path-based gesture is essential.”

 

  • 2.5.2 Pointer Cancellation (A)

See the example: “Problem: I went to hit the “Mute” button and accidentally touched the “End Call” button instead. It hung up immediately.
Works well: In another web conferencing application, if I accidentally touch the “End Call” button, I can just slide my finger off the “End Call” button and it won’t end the call.”

 

  • 2.5.3 Label in Name (A)

“For user interface components with labels that include text or images of text, the name  contains the text that is presented visually.” This is especially useful with the use of voice recognition: the action the user says out loud should be the one implemented in the code and visible on the screen.

 

  • 2.5.4 Motion Actuation (A)

“Functionality that can be operated by device motion or user motion can also be operated by user interface components  and responding to the motion can be disabled to prevent accidental actuation […]”

 

  • 2.5.5 Target Size (AAA)

“The size of the target for pointer inputs is at least 44 by 44 CSS pixels.”

 

  • 2.5.6 Concurrent Input Mechanisms (AAA)

This idea here is that users should be able to switch from one mode of input to another (mouse, keyboard, touchscreen, stylus…)

 

4.1 Compatible

  • 4.1.3 Status Messages (AA)

Automated messages to notify from an important background task. See the example the website gives: “Problem: I selected a class for the conference, but I can’t tell if it got added to my schedule.
Works well: When I add a meeting to my calendar, I hear a confirmation.”

 

WCAG 2.1 is a step forward in inclusivity and takes into account the new ways of using the web, with success criteria about the use of mobile devices and voice recognition, among other things. Thanks to W3C, developers and designers keep making progress in creating more inclusive content.

 

All quotes come from the W3C webpage, that will be helpful if you too plan on making your website more accessible.

Have a cookie // We use cookies to ensure that we give you the best experience on our website.