Operable
Users must be able to use and move around the interface, no matter what input method they use.
Key point
Operable means people can control technology in many ways, such as using a keyboard, switch, voice, eye tracking, and more. Designing only for mouse users leaves out many people who have trouble moving their hands.
Keyboard accessible
All features must work using only a keyboard because many people with movement disabilities cannot use a mouse.
Example
A user who controls their computer with one switch moves through page parts using the Tab key. If a dropdown menu opens only when the mouse moves over it, that user cannot use it at all.
Enough time
Users should be able to finish tasks without feeling rushed or being stopped unexpectedly.
Example
A banking website that logs users out after two minutes of not doing anything might be okay for someone who types fast. But a user with a motor disability who types slowly might have their session end before they finish filling out a form.
Seizures and Physical Reactions
Content must not have flashing lights or movement that could cause seizures or make people feel uncomfortable.
Example
A flashing animated ad can cause a seizure in someone with photosensitive epilepsy, even if they did not choose to see the animation.
Navigable
Users need ways to find content, understand where they are, and move through pages easily.
Example
A user who uses a keyboard moves with skip links to go past the main menu and reach the page content directly, saving many tab presses on each page they visit.
Input modalities
The function must work with many types of input, not just keyboards, but also touchscreens and pointer devices.
Example
A mobile screen that needs a hard swipe to work leaves out users who can only tap, like someone with a hand tremor who can use just one finger.
Key point
Input Modalities was added in WCAG 2.1 to cover mobile and touch devices that the original rules did not fully include. It works together with Keyboard Accessible and does not replace it.