WCAG 2.2 · Guideline 2.5 · Operable
Input Modalities
Touch, pointer, voice, and motion all have to work, not only the keyboard.
This is the guideline where the version of WCAG a law names changes the answer most. Guideline 2.5 did not exist in WCAG 2.0, so a regulation pointing at the 2008 standard asks for none of it. WCAG 2.1 added the guideline and its first six criteria. WCAG 2.2 added the only two it has ever carried at Level AA. It is the one guideline WCAG has ever gained, and every rule inside it is younger than the layer around it.
Six A/AA success criteria live here, out of eight. The guideline's own one-line text is the part worth carrying. It asks you to make things work through inputs beyond keyboard, which answers the developer who says the feature is keyboard accessible already. That answer is not good enough here, and the reason is mechanical rather than a matter of comfort. On a touchscreen with VoiceOver or TalkBack running, the screen reader takes your swipe or your drag before the page ever sees it. Without a single-pointer alternative the function is simply out of reach. And the guideline is a heading over six rules rather than a rule of its own.
- Rules
- 6
- Level A
- 4
- Level AA
- 2
- Human testing only
- 4
All 6 Input Modalities rules
- 2.5.1Level APointer GesturesAnything a multipoint or path-based gesture does has to be reachable with a single pointer that does not depend on the path, unless the gesture is genuinely essential.Human testing3 fixes
- 2.5.2Level APointer CancellationFor anything operated with a single pointer, one of four things has to be true.Human testing3 fixes
- 2.5.3Level ALabel in NameWhere a control has a visible label made of text, its accessible name has to contain that text.Partly scannable5 fixes
- 2.5.4Level AMotion ActuationTwo things are required together here, not one.Human testing2 fixes
- 2.5.7Level AANew in 2.2Dragging MovementsThis criterion is new in WCAG 2.2.Human testing2 fixes
- 2.5.8Level AANew in 2.2Target Size (Minimum)This criterion is new in WCAG 2.2.Partly scannable1 fixes
Level AAA in this guideline
2 enhanced criteria sit under 2.5. They are outside the level almost every law names, so our audits treat them as reference rather than scope. Some are still worth adopting, and the Level AAA hub says which.
- 2.5.5Level AAATarget Size (Enhanced)Pointer targets need to measure at least 44 by 44 CSS pixels, against 24 by 24 at Level AA.Not graded1 fixes
- 2.5.6Level AAAConcurrent Input MechanismsContent must not restrict which input methods somebody can use, unless the restriction is essential, needed for the security of the content, or needed to respect the reader's own settings.Not graded1 fixes
What goes wrong here
These are the failures we find repeatedly under 2.5, across sites of every size.
- Tap targets fall under 24 by 24 CSS pixels and sit packed together. Spacing can rescue an undersized target, and knowing which one you are relying on matters when you write the finding.
- A feature works only through a multi-point or path-based gesture, such as pinch to zoom or a two-finger swipe.
- An action fires on touch-down with no way to abort it. Firing on release is one of four ways to satisfy this, and an on-screen keyboard firing on down is the case the rule expressly allows.
- The visible label is not contained in the accessible name, so a spoken command that reads the button aloud does not match it.
- A drag interaction has no single-pointer alternative that works without dragging.
Who it affects
- People with tremor or limited dexterity, who miss small targets and land on the neighbouring one.
- People using speech input, who say what they see. When the visible name is not inside the accessible name, the command fails and the reason is invisible to them.
- People operating a device one-handed, permanently or for the afternoon, for whom a two-finger gesture is a barrier and a drag can be anywhere from awkward to impossible depending on the device and the grip.
- Anyone using a phone while moving, where accuracy drops for reasons that have nothing to do with disability.
How to work through it
- 1Measure the target itself first, in CSS pixels, then check the spacing separately. For a target under 24 pixels, the test is whether a 24-pixel circle centred on it would overlap a circle centred on any neighbour.
- 2Apply the exceptions before writing anything up. An equivalent control elsewhere on the page, a target inline in a sentence, a size the browser controls, and a size essential to the information all take a target out of scope.
- 3List every gesture where the path travelled matters or more than one contact point is needed, and confirm each has an alternative. A single-finger swipe is still path-based, so it needs an alternative of its own rather than serving as one. The alternative has to work with a single pointer and without tracing a path, which in practice means a button somebody can operate in one place.
- 4Handle dragging on its own. It has an AA criterion of its own, and a single-pointer alternative to a drag does not by itself prove the keyboard can do it.
- 5Compare each control's visible label against its accessible name and look for text in the label that is missing from the name. Any extra text in the name is fine; the requirement is inclusion, not equality.
- 6Check what happens on touch-down. One of four things has to be true: nothing fires on down, or the action completes on up with a way to abort or undo, or the up event reverses the down, or completing on down is essential to what the control is.
How the levels build
Level A covers four: path-based and multipoint gestures need an alternative, pointer actions can be cancelled, the visible label is contained in the accessible name, and anything operated by tilting or shaking the device has a normal control too. Level AA adds the two that arrived in WCAG 2.2: dragging movements need a single-pointer alternative, and targets meet 24 by 24 CSS pixels or the spacing rule. Level AAA sets a 44 by 44 CSS pixel target, which arrived first in WCAG 2.1 and which the later AA minimum was written beneath rather than above. It also asks that content not restrict which input methods the platform offers, unless the restriction is essential, needed for security, or needed to respect a setting the user chose.
Other Operable guidelines
- 2.1Keyboard AccessibleEvery task has to be finishable from the keyboard alone.
- 2.2Enough TimeTime limits and moving content have to be under the reader's control.
- 2.3Seizures and Physical ReactionsNothing on the page may flash or move in a way that can hurt somebody.
- 2.4NavigableReaders have to be able to find their way around and know where they are.
Part of the Operable principle · browse by level: Level A · Level AA · or the full 55-rule library.
See how your site does against these rules.
An expert review plus a real blind screen-reader user, on up to 10 pages, every finding with its screenshot, criterion, and fix. $499, report in 5 business days.