You made it! This is the last in our series on the new WCAG 2.1 Success Criteria. We finish with the last level AAA success criterion, 2.5.6 Concurrent Input Mechanisms. It is under guideline 2.5, Input Modalities.
Guideline 2.5 Input Modalities
Make it easier for users to operate functionality through various inputs beyond keyboard.
2.5.6 Concurrent Input Mechanisms (Level 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.
Overview
The user must be able to switch between different input devices while working with your content. You can not assume that someone on a mobile device will only use touch. They may also use speech input and they may attach a keyboard. A speech input user may prefer to switch to the keyboard when entering a password to protect privacy. Many laptop computers provide a keyboard and touch screen and the user can switch from one to the other.
Certain applications require the use of a particular input device to perform a task. For example, a mobile application that teaches the finger positions of guitar chords requires a touch interface. The touch interface is essential to teaching the user to play the guitar.
Who Benefits?
People with repetitive stress injuries may use different input devices to avoid overuse or pain. They may switch between speech, mouse, and keyboard depending upon the content. People with hand tremors who have difficulty activating small targets may prefer using the keyboard to navigate to items. Everyone benefits when we can use the input mechanism of choice for each task. An example is my iPad Pro with a detachable keyboard. I usually prefer the keyboard because I can type faster on a physical keyboard. However, if I fold the keyboard away, the onscreen keyboard displays and I can continue with it. When I unfold the physical keyboard, the onscreen keyboard goes away. Correctly coded applications will switch between the keyboard methods seamlessly.
Takeaways
Test your content with various input mechanisms, speech, mouse/pointer, touch, and keyboard. Make certain the user can switch between different input types.
For Developers
Developers must not rely on only touch events or only mouse events. The W3C Pointer Events 2.0 specification aims to generalize mouse and touch events. It is going through the W3C process and should reach full recommendation status soon. It will hopefully gain better support in browsers and be a viable option to support both touch and pointer events.
Don’t forget to include keyboard support as required by guideline 2.1 Keyboard Accessible. Also, review the posts on 2.1.4 Character Key Shortcuts and 2.5.3 Label in Name. Select visible labels and character key shortcuts to support speech input users.
We are done with this series! I encourage you to celebrate your newfound WCAG 2.1 knowledge with your favorite dessert or beverage or both! I know I will.
