Web Content Accessibility Guidelines (WCAG) 2.1

Patrick Lauke June 8, 2018Technical

This week (5 June 2018) saw the release of the Web Content Accessibility Guidelines (WCAG) 2.1 as a W3C recommendation – meaning that the working group (which, among many others, included members from TPGi) considers the guidelines stable and ready for implementation.

WCAG 2.1 builds on top of WCAG 2.0, and it still incorporates all the guidelines and success criteria of 2.0. As such, it is backwards-compatible: a site that adheres to WCAG 2.1 automatically also adheres to WCAG 2.0.

The aim of WCAG 2.1 is to provide guidance for aspects that were previously absent or underrepresented in 2.0. To this end, WCAG 2.1 includes 1 new overarching guideline (Guideline 2.5 Input Modalities) with 6 success criteria, as well as 11 new success criteria that fall under the existing guidelines already present in 2.0. These 17 new success criteria aim to address issues that affect:

people using “mobile” devices (though note that this term is somewhat archaic, as the boundaries between traditional categorizations of “desktop”, “mobile”, “tablet” are constantly blurring)
people with low vision who may be using screen magnification or large text/zoom
people with cognitive and learning disabilities
people using speech input / dictation software

The new success criteria

Guideline 1.3 Adaptable

1.3.4 Orientation (Level AA)

Content does not restrict its view and operation to a single display orientation, such as portrait or landscape, unless a specific display orientation is essential.

This criterion is especially important in the context of mobile/tablet sites, to ensure that they don’t expect/limit their use to any particular orientation, as certain users may have their device statically mounted in a fixed orientation, and cannot easily change the orientation of their device.

1.3.5 Identify Input Purpose (AA)

The purpose of each input field collecting information about the user can be programmatically determined when:

The input field serves a purpose identified in the Input Purposes for User Interface Components section; and

The content is implemented using technologies with support for identifying the expected meaning for form input data.

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.

These two criteria are aimed primarily at users with cognitive and learning disabilities. Ensuring that input and content purpose can be programmatically determined means that additional tools/assistive technologies have the potential to aid users to better understand and operate web content. For instance, in the context of login/account registration processes, programmatically identifiable form controls allow tools such as password managers to prefill/autofill certain known fields, which can greatly aid users with cognitive/memory issues.

Guideline 1.4 Distinguishable

1.4.10 Reflow (AA)

Content can be presented without loss of information or functionality, and without requiring scrolling in two dimensions for:

Vertical scrolling content at a width equivalent to 320 CSS pixels;

Horizontal scrolling content at a height equivalent to 256 CSS pixels;

Except for parts of the content which require two-dimensional layout for usage or meaning.

This criterion fills a gap from WCAG 2.0. While 2.0 only required sites to allow users to zoom up to 200% without a loss of content/functionality, it did not cover scenarios in which zooming would result in content that then required horizontal and vertical scrolling.

1.4.11 Non-Text Contrast (AA)

The visual presentation of the following have a contrast ratio of at least 3:1 against adjacent color(s):

User Interface Components

Visual information used to indicate states and boundaries of user interface components, except for inactive components or where the appearance of the component is determined by the user agent and not modified by the author;

Graphical Objects

Parts of graphics required to understand the content, except when a particular presentation of graphics is essential to the information being conveyed.

WCAG 2.0 only mandated specific minimum contrast requirements for text. This criterion now extends requirements to all user interface components (which may be purely graphical), their individual states, and general graphical objects (such as non-text-based icons).

1.4.12 Text Spacing (AA)

In content implemented using markup languages that support the following text style properties, no loss of content or functionality occurs by setting all of the following and by changing no other style property:

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.

Exception: Human languages and scripts that do not make use of one or more of these text style properties in written text can conform using only the properties that exist for that combination of language and script.

In combination with the pre-existing criterion 1.4.5 Images of text, this ensures that users (particularly users with low vision) who benefit from specific text adaptations can set these without adversely impacting the layout/functionality of a site.

1.4.13 Content on Hover or Focus (AA)

Where receiving and then removing pointer hover or keyboard focus triggers additional content to become visible and then hidden, the following are true:

Dismissable

A mechanism is available to dismiss the additional content without moving pointer hover or keyboard focus, unless the additional content communicates an input error or does not obscure or replace other content;

Hoverable

If pointer hover can trigger the additional content, then the pointer can be moved over the additional content without the additional content disappearing;

Persistent

The additional content remains visible until the hover or focus trigger is removed, the user dismisses it, or its information is no longer valid.

Exception: The visual presentation of the additional content is controlled by the user agent and is not modified by the author.

This criterion is of particular relevance for low vision users, as it aims to ensures that content that appears on hover/focus is operable even when using screen magnification.

Guideline 2.1 Keyboard Accessible

2.1.4 Character Key Shortcuts (A)

If a keyboard shortcut is implemented in content using only letter (including upper- and lower-case letters), punctuation, number, or symbol characters, then at least one of the following is true:

Turn off

A mechanism is available to turn the shortcut off;

Remap

A mechanism is available to remap the shortcut to use one or more non-printable keyboard characters (e.g. Ctrl, Alt, etc).

Active only on focus

The keyboard shortcut for a user interface component is only active when that component has focus.

This criterion ensures that keyboard shortcut functionality is not accidentally triggered by users – something that can happen quite often in the case of speech input users when their assistive technology mistakes speech for specific keystrokes which are then sent to the page.

Guideline 2.2 Enough Time

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.

This criterion fills a gap from WCAG 2.0, which already covered some related aspects in 2.2.1 Timing Adjustable.

Guideline 2.3 Seizures and 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.

This criterion is of particular relevance for users with vestibular disorders or vertigo, for whom motion effects on the screen can cause discomfort.

Guideline 2.5 Input Modalities (new guideline in 2.1)

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.

Particularly on touch-screen devices it is common for content to provide functionality through gestures (such as swipes and pinch-to-zoom). This criterion requires that the same functionality is also available to users who are unable to perform these gestures, by providing controls that can be operated with a single tap/click.

2.5.2 Pointer Cancellation (A)

For functionality that can be operated using a single pointer, at least one of the following is true:

No Down-Event

The down-event of the pointer is not used to execute any part of the function;

Abort or Undo

Completion of the function is on the up-event, and a mechanism is available to abort the function before completion or to undo the function after completion;

Up Reversal

The up-event reverses any outcome of the preceding down-event;

Essential

Completing the function on the down-event is essential.

This criterion aims to prevent accidental activations using a pointer (mouse, stylus, finger on a touchscreen) – particularly relevant for users who may not have the fine motor skills required to always accurately operate their pointer device / use a touchscreen.

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 criterion ensures that speech input users are able to unambiguously navigate to and activate controls by announcing the visible label of the control.

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, except when:

Supported Interface

The motion is used to operate functionality through an accessibility supported interface;

Essential

The motion is essential for the function and doing so would invalidate the activity.

Particularly on portable (mobile/tablet) devices, it is possible for web content to react to motion (with functionality such as “shake to undo”, or by using the tilt of the device as a directional input). This criterion ensures that an alternative that does not require device motion is available.

2.5.5 Target Size (AAA)

The size of the target for pointer inputs is at least 44 by 44 CSS pixels except when:

Equivalent

The target is available through an equivalent link or control on the same page that is at least 44 by 44 CSS pixels;

Inline

The target is in a sentence or block of text;

User Agent Control

The size of the target is determined by the user agent and is not modified by the author;

Essential

A particular presentation of the target is essential to the information being conveyed.

This criterion aims to ensure that all actionable controls in web content provide a sufficiently large “hit” area. This is relevant for users who may lack fine motor control.

2.5.6 Concurrent Input Mechanisms (AAA)

Web content does not restrict use of input modalities available on a platform except where the restriction is essential, required to ensure the security of the content, or required to respect user settings.

This criterion aims to ensure that people can use and switch between different modes of input when interacting with web content. Users may employ a variety of input mechanisms when interacting with web content. These may be a combination of mechanisms – such as a keyboard or keyboard-like interfaces – and pointer devices – like a mouse, stylus or touchscreen. As an example, this criterion should prevent sites from detecting the presence of a touchscreen and a touch-enabled laptop, or on a tablet with a paired physical keyboard and mouse, and simply assuming that touch is the only input mechanism the user will want to use.

Guideline 4.1 Compatible

4.1.3 Status Messages (AA)

In content implemented using markup languages, status messages can be programmatically determined through role or properties such that they can be presented to the user by assistive technologies without receiving focus.

In broad terms, this criterion would require messages (such as alerts, “toast” notifications, or any other status messages appearing on the screen) to be implemented in such a way that they can be announced by assistive technologies – for instance, using ARIA live regions.

Adopting the new standard

WCAG 2.0 is still a valid standard, which is used (often by being incorporated, either directly or by reference) as a measure of digital accessibility in a variety of industry standards, legislations and directives (such as the recently revised Section 508 of the Rehabilitation Act and the new European standard on Accessibility requirements suitable for public procurement of ICT products and services in Europe (EN 301 549)). It is likely that in due course these will be updated to reference WCAG 2.1. However, as WCAG 2.1 is backwards-compatible with WCAG 2.0, website owners and authors are encouraged to begin following the new guidance included in 2.1 – they will still comply with the success criteria that are unchanged from 2.0, while the new guidelines in 2.1 will help towards creating a better, more accessible experience for their users (as well as ensuring that, once standards and legislations do update to WCAG 2.1, their sites will already be compliant).