Skip to main content
WCAGrules
Quick navigation

Glossary · Accessibility term

Motor disability

Also called: Mobility impairment

Motor disability covers anything that affects movement, strength, precision or sensation, from tremor and arthritis to multiple sclerosis, repetitive strain, paralysis and missing limbs. The web consequence is much the same whatever the cause, which is that mouse precision cannot be assumed. People navigate by keyboard, by switch, by voice, by eye tracking, with a head pointer or a mouth stick, or with a mouse they simply cannot aim well. The barriers overlap heavily across all of it. Small targets sitting close together. Anything that only happens on hover. A form that times out mid-answer. Anything that has to be dragged. The group is also much wider than a list of diagnoses. A broken wrist, a bad day with a fluctuating condition and holding a baby all produce the same functional need, and somebody in that position is far less likely to know an accessibility setting exists, let alone where to find it.

In practice

Full keyboard support is the foundation and it is not the whole answer, which is the correction most teams need. W3C says plainly that keyboard operability does not satisfy the pointer gesture rule. Some people use a pointing device and cannot be precise with it. Telling one of them to use a keyboard shortcut instead is asking them to switch to a harder tool. Both routes have to work.

Chording is the other thing to watch, and the useful version of that point is narrower than the one usually made. Plenty of people here cannot hold two keys down at once, and the platforms answer that with sticky keys, which lets the modifier be pressed first and released. So the question is not whether you used a modifier. It is whether the interaction still works when the two presses arrive one after the other, which rules out anything timing the gap, and whether a modifier plus a pointer action has a route that does not need the pointer at all. It is also why single-character shortcuts hurt this group as well as speech users.

W3C's own list of what helps runs wider than target size. Large clickable areas, enough time to finish, error correction on forms, a visible focus indicator, and a way to skip repeated blocks. The last two get filed as screen reader work on most sites, and they were written for this group too. Somebody driving focus one slow keystroke at a time pays for every repeated menu on every page.

Why it matters

This is where the standard has moved most recently. Three of the criteria added in WCAG 2.2 sit at Level AA and were written for this group, covering target size, an alternative to dragging, and focus not being hidden behind something. There is a version consequence attached that catches suppliers out. The whole guideline covering pointer input, target size, dragging and motion arrived in WCAG 2.1. Anybody working to WCAG 2.0, which is still what Section 508 names, carries none of that guideline's obligations, though the Section 508 standards carry hardware and software provisions of their own that reach some of the same ground. What the gap changes is what a WCAG audit against that version will even look for.

What tends to break

A close button eight pixels across sitting next to the one that empties the basket. A menu that only opens on hover, so it closes every time the pointer wobbles off the path. A seat map you have to drag to pan. A checkout that times out while somebody is still typing an address at four keystrokes a minute. None of those is a mistake anybody made on purpose, and all four are the same decision made without this group in the room.

Where this shows up on the site

Related terms

Knowing the word is the easy part.

Find out where your own site stands. The free scan checks 10 pages in a real browser against all 90 supported automated rules, separates 27 best-practice checks from its WCAG findings, and names the rule behind every result.

Run the free scan

Go somewhere useful

Find tools, resources and your workspace.

29 destinations