WCAG 2.1: What’s new? – Part 2

Keyboard commands (A)

If websites offer their own keyboard shortcuts with letters, numbers or other characters, one of the following conditions must be met. These are intended to avoid overlapping with browser or technological keyboard shortcuts.

1. Users can deactivate the hot key.
2. Users can modify the keyboard shortcut with additional function keys such as Ctrl, Alt or Cmd.
3. The keyboard shortcut is only active if the element currently has the focus.

This criterion improves accessibility for people who use voice input to navigate a website. This criterion also improves accessibility for people who, for example, have a tremor and press the wrong key by mistake.

Pointer gestures (A)

With this newly introduced criterion, WAI is reacting to new operating concepts on touch screens.

This guideline states that the user must also be able to perform actions that must be performed with complex gestures such as wiping or multiple points simultaneously with simpler gestures. Such simple gestures include, for example, single tips, double tips, and long pressing.

Pointer input and abort (A)

A click with the mouse or on the touch screen should not trigger any unintentional events. This criterion is particularly relevant for motor impairments such as tremor or in special situations such as in trams.

In order to understand this criterion, a distinction must be made between down events and up events. In the case of down events, pressing a mouse button alone or touching the touch screen alone triggers an action. For up-events, the action is only triggered when the finger leaves the mouse button or the touchscreen.

If an action can be triggered with one click, at least one of the following requirements must be met:

1. The triggered functions do not happen on the down event.
2. The functionality is triggered on the up event and it is possible to either cancel it before the up event takes place or undo it afterwards.
3. The up event cancels what happened on the down event.
4. The functionality on the down event may only be triggered if there is an important reason for doing so. Triggering the functionality on the down event must be done for an important reason.

An example for point 2: If you use a mouse and hold a button to delete a file on the dropbox, you should be able to move the mouse pointer away from the button and release it without anything happening.

Visible labels (A)

This criterion improves operation by speech input. In order for links and switches to be operated by voice input, they must have a visible label. This corresponds to the name of the element.

This is easy to achieve by using HTML elements such as anchor tags and buttons correctly and writing explanatory text labels.

Tip: If you replace text with a symbol on a surface component, you can still get a screenreader to read the text using the aria-label attribute.

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

If you follow this criterion, you will improve accessibility for people with visual impairments who use a screen reader. You also improve accessibility for people who use speech to surf the web.

Motion confirmation (A)

If physical movements of the smartphone or the user trigger a functionality, there must be an alternative. If, for example, I can undo an action by shaking my iPhone, it must also be possible with the mouse and keyboard.

In addition, I must have the option of completely deactivating control by moving my device. People with chronic tremor should be protected from constant involuntary input.

Status messages (A)

In order to meet this criterion, to follow this Directive, users using assistive technologies must receive a notification when content updates dynamically. The status message should be sent without a visual focus on the updated content.

For example, you are browsing a news site that has a Twitter feed embedded. It would be annoying if every time a new tweet appeared, you were automatically scrolled up again to see the new tweet.

A good solution to such status messages is to use ARIA live regions. These three snippets of code explain 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>