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.
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.
Success Criterion: For functionality that can be operated using a single pointer, at least one of the following must apply:
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.
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.
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.
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.