WCAG 2.1 - What’s it all about?

WCAG 2.1 - What’s it all about?

Presented by Allison Ravenhall @RavenAlly Digital Accessibility Sensei at Intopia @Intopia

The W3C publish the Web Content Accessibility Guidelines (WCAG)

Version 1.0 was published in 1999. Version 2.0 was published in 2008. Version 2.1 was published in 2018.

WCAG 2.1 = WCAG 2.0 + 17 new success criteria

Level A (5 new success criteria)

2.1.4 Character Key Shortcuts

Prevent keyboard shortcut clashes with screen readers

Examples of potential keyboard clashes

Single-key keyboard commands for Microsoft Outlook, JAWS and Slack. JAWS uses keyboard commands that are also used by these web applications.

If you're going to build single-key keyboard commands, you must support at least one of:

1. Turn off
2. Remap
3. Active only on focus

2.5.1 Pointer Gestures

Define simple pointer gestures

Single digit and single interaction is simple. Multiple digit and/or multiple interaction is complex.

Pinch = complex Tap = simple Screenshot of Google maps app on tablet with single finger tap and two-finger pinch icons.

Simple gestures = one finger, single interaction

1. Tap
2. Double-tap
3. Long-press

Complex gestures = multiple fingers and/or multiple movements

1. Swipe
2. Tap & drag (slider)
3. Tracing a path
4. Pinch zoom
5. One finger hold, second finger tap
6. Multi-finger tap or swipe

Exceptions to simple gestures requirement

1. Essential gestures
2. User agent gestures (e.g. swipe to scroll browser)
3. Assistive tech gestures (e.g. VoiceOver, TalkBack)

2.5.2 Pointer Cancellation

Enable users to cancel pointer gestures

Four scenarios to support pointer cancellation

1. No down-event - fire event on release
2. Up reversal - press to fire event, release to stop event
3. Provide abort or undo after the event
4. OK to fire on down event if it’s essential e.g. weapon fire in game

2.5.3 Label in Name

Start element labels with (unbroken) on-screen content

If there’s five “Add to Cart” buttons on screen, how is a screen reader user meant to tell them apart? A sighted voice control user can activate a specific button by saying “Click Add to cart” then saying the number applied to the button.

If the buttons have been enhanced with extra off-screen content, then a screen reader user can identify them more easily. “Add to cart” on-screen versus “Add apple to cart” for a screen reader. However, the voice control software doesn’t recognise “Add to cart” as a button anymore because that button label isn’t in the code anymore - it looks up the screen reader text, not the visible text.

If the screen reader label is rearranged so the on-screen label is read first, in full, unbroken, then screen reader users can uniquely identify buttons and voice control users can activate buttons by name. e.g. “Add to cart” on-screen, “Add to cart, apple” in code.

2.5.4 Motion Actuation

Provide alternatives to motion functions

Screenshot of tilt maze in Zelda Breath of the Wild on Nintendo Switch

A tilt maze gives no alternative to motion input. The player must tilt the controller to move the ball through the maze. This fails the requirement.

Screenshot of Mario Kart tilt controls setting

The Mario Kart game allows players to decide whether or not they want to user tilt controls. This enables people who can’t control the tilt steering to use the controller buttons to steer their kart instead.

Motion actuation exception #1

If movement is an essential part of the experience, then an alternative doesn’t need to be provided. Example: Just Dance game for Nintendo Switch tracks user motion and scores accuracy and timing. Without movement, there would be no game - it’s essential to the experience.

Motion actuation exception #2

If there is an accessible interface that can simulate the player motion, then the game/site/app itself doesn’t need to provide a non-motion experience. Example: XBox adaptive controller.

Level AA (7 new success criteria)

1.3.4 Orientation

Don’t make users read like this (text is presented sideways)

If content is locked to a particular orientation (portrait or landscape), this makes it hard to use for people with limited mobility who have their devices mounted on a stand.

It’s better for content to detect and adapt to the current device orientation.

Sometimes single orientation is essential. Example: piano can only be presented in landscape.

1.3.5 Identify Input Purpose

Add metadata to forms to enable autofill

A long list of all of the personal data input field types that can have autocomplete applied. Examples: given-name, family-name, address-line1, postal-code, tel, email.

Code example applying autocomplete to fields expecting a home email address and a password

<input type=”email” autocomplete=”home email” /> <input type=”password” autocomplete=”off” />

1.4.10 Reflow

Build responsive sites

Screenshot of a fixed-width desktop site, 100% zoom, one vertical scrollbar.

Screenshot of the same fixed-width desktop site at 400% zoom - one vertical and one horizontal scrollbar. People aren’t used to scrolling sideways and will likely miss information that’s “off to the right”.

Screenshot of a responsive mobile site at 400% zoom - one vertical scrollbar only. Big content has rearranged and flowed down.

Exceptions to Reflow

It’s OK to have horizontal scrollbars to maintain layout of: Data tables, images/diagrams/maps, video/games, presentations

1.4.11 Non-Text Contrast

Make graphics and UI elements really pop

All of the minimum AA contrast requirements

Headings = 3.0 : 1 Body text = 4.5 : 1 Element outlines = 3.0 : 1 Icons/graphics = 3.0 : 1 State styles = 3.0 : 1

1.4.12 Text Spacing

Text shouldn’t truncate, overlap, or overrun when users increase spacing

Sites need to maintain good layout with spacing up to these amounts: Letter spacing x 0.12 Word spacing x 0.16 Line spacing x 1.5 Paragraph spacing x 2

1.4.13 Content on Hover or Focus

Make tooltips and submenus more usable

First principle: Dismissable Keyboard users should be able to dismiss a menu at any time without moving to a specific element e.g. press Tab.

Second princple: Hoverable Pointer users should be able to move their pointer anywhere over the trigger element and the triggered content (e.g. a tooltip) without the content disappearing

Third principle: Persistent If a user triggers a menu or tooltip, it shouldn’t automatically disappear after some time. It should stay visible as long as the keyboard focus or pointer is within it.

4.1.3 Status Messages

Mark up status messages for assistive technology

Code example of a notification

<span role=”status”> Loading, please wait…</span>

Levels of announcement urgency

Alerts are Assertive (immediate) Status and Log are Polite (queued after current announcement) Marquee and Timer are Off (no announcement)

Bootstrap uses role=”alert” Screenshot of code sample of Bootstrap notification.

Summary

Keyboard shortcuts Simple gestures Orientation Metadata Responsive Pointer cancellation Non-text contrast Speech-friendly labels Text spacing Motion alternative Hover / focus behaviour Mark up status messages

Get accessible! Allison Ravenhall @RavenAlly Digital Accessibility Sensei at Intopia @Intopia