The new guidelines in WCAG 2.1 explained

WCAG stands for Web Content Accessibility Guidelines and is an International established set of guidelines for accessible content on the Internet. These guidelines are mainly for people with various disabilities, but also for different devices used for browsing websites.

WCAG is maintained by the World Wide Web Consortium (W3C), the main standards organisation for the Internet. The current version (WCAG 2.0) was published in 2008 and became an ISO standard (

When using the image slider Flexslider 2, you can go back and forth between images by swiping to the left and to the right. However, you can do the same thing with simpler gestures like tapping the arrow icons or the image thumbnails.

Remember: Even if users have great motor skills, the possibility to perform complex gestures might not be obvious to them.

Following this guideline will improve accessibility for users with limited motor skills or not enough fingers (!) for multi-touch gestures.

2.5.2 Pointer Cancellation (A)

This guidelines says that when you interact with a screen by clicking, tapping and long pressing at least one of the following statements must be true:

1. The triggered functionality doesn’t happen on the down-event.
2. The functionality is triggered on the up-event and it’s possible to either cancel it before the up-event occurs or undo it afterwards.
3. The up-event cancels what happened on the down-event.
4. Triggering the functionality on the down-event has to occur for some important reason.

An example of point 2: If you’re using a mouse and press down on a button for deleting a file on Dropbox, you should be able to move the mouse cursor away from the button and release it and nothing should happen.

2.5.3 Label in Name (A)

For succeeding with this guideline, text that is shown on interface components like buttons must be able to be:

• Read to users of assistive technologies like screen readers
• Triggered by voice commands by users who take advantage of speech recognition software

This is easy to succeed at if you use HTML elements like anchor tags and buttons correctly and write explanatory text labels.

Tip: If you replace text with an icon on an interface component, you can still make a screen reader read text to its user with the help of the aria-label attribute.

<button aria-label="Search"> <span class="icon-search"></span> </button>

Following this guideline will improve accessibility for people with visual impairment who use screen readers. It will also improve accessibility for users who use speech input for browsing a website.

2.5.4 Motion Actuation (A)

For following this guideline, functionality that is triggered by moving one’s mobile device must also be able to be triggered by interacting with interface components like buttons and sliders.

Responses to (accidental) motion must also be able to be turned off, unless:

• The motion is supported through an accessible interface.
• The motion is essential for the functionality.

The shake to undo feature used on native iOS and Android apps could be very troublesome if you have hand tremors. Luckily, I haven’t seen it be used on any websites.

Following this guideline will improve accessibility for users who mount their tablets and smartphones to their wheelchairs or have trouble moving them due to limited motor skills or because their hands are busy at the moment.

2.5.5 Target Size (AAA)

For succeeding with this guideline, a clickable element must have a height and width of at least 44 ⨯ 44 pixels. However, it can be smaller if:

• Its functionality can be achieved through another clickable element of 44 ⨯ 44 pixels.
• It’s located in a block of text, like a regular underlined link.
• Its size is determined by the device and browser the user is using (radio buttons, checkboxes).
• It must have this look and size in this particular context in order to make sense.

Following this guideline will improve accessibility for people who have hand tremors, large fingers and use mobile devices with touch input (especially with just one hand).

2.5.6 Concurrent Input Mechanisms (AAA)

This guideline states that you must never disallow users to use, switch between or add and remove different mechanism for input like mouse, keyboard, stylus, touch input or voice input. Even if it means ignoring the most common mechanism for interacting with a certain piece of content.

Following this guideline will improve accessibility for people with limited motor skills who prefer or must use a certain input mechanism even when it’s uncommon. For example: Using a keyboard or mouse when operating a tablet.

4.1.3 Status Messages (AA)

For following this guideline, content that is updated dynamically must be notified to users of assistive technologies (like screen readers) without getting visual focus.

For example: You’re browsing a news website with a Twitter feed at the top of the site. It would be infuriating if every time a new tweet appears, you would automatically be scrolled back up to the top to see the new tweet.

A great way to solve this for users of screen readers is to use ARIA Live Regions. Here are three code snippets explaining how it works:

<div role="status" aria-live="off"> When this text is updated, users with screen readers will not be notified at all. </div> <div role="status" aria-live="polite"> When this text is updated, users with screen readers will be notified if they aren't doing anything else. </div> <div role="status" aria-live="assertive"> When this text is updated, users with screen readers will be notified immediately regardless of what they're doing. </div>

Following this guideline will improve accessibility for users with visual impairment, especially for those who use screen readers and are likely to zoom in on a website.

Wrapping up

Phew, that was the last of the new guidelines for WCAG 2.1. Is my post not updated or contains some mistakes? Please, let me know in the comment section and I’ll correct it.

Finally, remember that having great accessibility on your website will improve the user experience for all users.