Earlier this year, the Web Content Accessibility Guidelines (WCAG) received a welcomed update. Since 2008, WCAG 2.0 had been widely considered the standard in web accessibility. In those 10 years, advancements in web, mobile, and assistive technologies have been enormous, leaving gaps between the guidelines defined in WCAG 2.0 and some recent innovations. In June 2018, WCAG 2.1 was published to enhance the existing standards.
WCAG contains specific recommendations for making web content functional using input devices beyond a keyboard, for example, via a mouse pointer, a finger interacting with a touch screen, an electronic pencil or stylus, or a laser pointer. Developers should be aware that this is crucial to making a website accessible and compliance with the Americans with Disabilities Act (ADA). The devices people use as input methods vary greatly, and may include mouse input, touch input, keyboard input, and speech input.
To account for the need to navigate and operate controls through various input methods, WCAG 2.1 includes a new guideline: 2.5 Input Modalities.
Here are the four Level A success criteria that support the new Input Modalities guideline.
2.5.1 Pointer Gestures (Level A)
Success Criterion: 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.
Note: This requirement applies to web content that interprets pointer actions (i.e. this does not apply to actions that are required to operate the user agent or assistive technology).
The purpose of this checkpoint is to ensure that content can be operated using simple inputs on a wide variety of pointing devices. This is important in order to accommodate users who cannot perform multi-point or path-based gestures with precision, or who have pointing methods that lack the capability or accuracy. The simpler the gesture, the easier it may be for people with certain cognitive or motor impairments to perform, whether they use a head mouse, a sip and puff device, or other assistive technology.
2.5.2 Pointer Cancellation (Level A)
Success Criterion: For functionality that can be operated using a single pointer, at least one of the following must apply:
- 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: Functions that emulate a keyboard or numeric keypad key press are considered essential.
Note: This requirement applies to web content that interprets pointer actions (i.e. this does not apply to actions that are required to operate the user agent or assistive technology).
The purpose of this checkpoint is to make it easier for users to prevent accidental or erroneous input and provide an outline for enabling users to cancel pointer operations.
2.5.3 Label in Name (Level A)
Success Criterion: For user interface components with labels that include text or images of text, the name contains the text that is presented visually.
Note: A best practice is to have the text of the label at the start of the name.
This checkpoint is intended to address the need for visual labels that users can also use programmatically. A label identifies the control to all users, and acceptable labels include alt-text, aria-label, and aria-labelled by attributes. Controls are often labeled with visual text, which some users then employ to navigate websites by speaking aloud the visual text labels of menus, links and buttons that appear on the screen.
Controls should also have an Accessible Name, which should match the visual text labels. With the help of visual text labels, speech input users can directly activate controls on a page. Text-to-speech users will better understand the content when labels that they hear match the visible text labels they see on screen.
2.5.4 Motion Actuation (Level A)
- Success Criterion: Functionality triggered by device motion or user motion should 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.
This checkpoint refers to intentional movement that would cause a specific action and the need for alternative controls for users with motor impairments, like tremors. For example, if shaking a mobile device cancels an action, there must be a clear and visible button that performs the same function.
Here to help you achieve accessibility
Talk to us to learn how we can help with all aspects of your digital accessibility efforts, or get started with a free and confidential website accessibility scan. We look forward to helping you achieve, maintain, and prove digital compliance.
