Motor Disabilities and Predictive Input
Most interfaces assume a steady hand and a mouse. For millions of people using tremor-affected hands, head pointers, switch devices, or tongue-driven cursors, that assumption is the first locked door.
The demos below let you test the problem directly.
How small is too small?
Try clicking each target. Now imagine doing it with a tremor, a head pointer, or a tongue-driven cursor. The smaller targets deliberately fall below accessible size minimums: that failure is the demonstration.
The keyboard test
Put your mouse away. Using only Tab, Shift+Tab, and Enter, try to submit both forms below. One is built with semantic HTML. One is not.
Form A
Form B
This form is intentionally broken. The controls below are styled div elements rather than real form fields, so they cannot be reached by keyboard or announced properly. This is a demonstration of inaccessible markup, not a working form.
Form B looks identical but is built from styled divs. The keyboard cannot reach it, and neither can a switch device, a sip-and-puff controller, or a tongue-driven cursor. Same pixels, closed door.
The action tax
Same task: pick a delivery day. Count what each design costs. Every click is effort, and effort adds up when movement is expensive.
Design A
Day: Mon
Actions used: 0
Design B
Actions used: 0
Design A demands up to five actions for what Design B does in one. Multiply that across a whole day of computing.
Mapping motor accessibility
What better looks like, one waypoint at a time.
Meet target size minimums as a floor, not a ceiling. Fingers, tremors, and pointers all need room.
Build with semantic HTML so every assistive device can reach every control.
Count the actions your design demands, then cut them. Every click is a cost someone pays in effort.
Test with a keyboard alone before shipping. If you cannot finish the task, neither can millions of users.
Mapped.