Mobility and Dexterity Disabilities

Motor and dexterity disabilities affect how users interact with input devices — whether that is difficulty using a mouse, limited hand movement, inability to use both hands simultaneously, or complete dependence on voice or switch-based input. These are among the most common adult-onset disabilities, affecting people after stroke, injury, surgery, or through progressive conditions.

Approximately 3.6 million Canadians over the age of 15 report a mobility-related disability. Motor disabilities are also the category most directly affected by the fundamental design decision of whether your website is operable without a mouse.

Types of motor disability

Type	Examples	Common causes
Upper limb impairment	Difficulty gripping, limited range of motion, tremors	Arthritis, Parkinson’s, carpal tunnel, injury
Paralysis	Inability to move one or more limbs	Spinal cord injury, stroke, ALS
Spasticity	Involuntary muscle contractions affecting control	Cerebral palsy, MS, stroke
Fatigue-related motor impairment	Pain or exhaustion limiting extended mouse or keyboard use	MS, fibromyalgia, chronic fatigue syndrome
No upper limb function	Navigating entirely without hands	High-level spinal cord injury

Assistive technologies

Developer Designer

Many motor disability users navigate entirely by keyboard — Tab, Shift+Tab, arrow keys, Enter, and Space. A site that requires a mouse excludes all keyboard-only users.

Switch access

Switch users operate their computer through one or more physical switches (buttons) that they can activate with a hand, arm, head, or foot. Switch access software (such as AssistiveTouch on iOS or Switch Access on Android) uses scanning — cycling through interactive elements automatically, with the user pressing the switch to select when the desired element is highlighted.

Switch navigation is extremely slow compared to keyboard or mouse. Complex interactions requiring many clicks, drag-and-drop, or precision targeting are major barriers.

Voice control

Voice control software lets users control the entire computer by speaking commands:

Dragon NaturallySpeaking / Dragon Professional (Windows) — industry standard
Voice Control (macOS and iOS, built-in)
Voice Access (Android, built-in)

Voice control users say things like “click Login”, “scroll down”, “tab to next field.” For this to work, interactive elements must have meaningful accessible names that match what the user would naturally say.

Eye tracking

Users with high-level paralysis may operate computers entirely through eye tracking — the cursor follows their gaze and dwell time triggers clicks. Eye tracking requires:

Large click targets (tiny buttons are almost unusable)
No hover-only interactions
Stable page layout (sudden content shifts cause mis-activations)

Head mouse / mouth stick

Users with limited arm function may use head-mounted pointing devices or a physical stick held in the mouth to control a cursor. These devices have lower precision than a standard mouse.

Adaptive keyboards

Ergonomic, one-handed, and onscreen keyboards assist users with limited typing ability. Onscreen keyboards are particularly common on touchscreens and for users without hand function.

Barriers on the web

Mouse-only interactions

Barrier: Dropdown menus open only on hover, drag-and-drop is the only way to sort items, custom widgets require click-and-drag — keyboard-only and switch users cannot perform these actions.
Assistive Technology: Keyboard, switch access, voice control
Design Consideration: All functionality must be operable by keyboard alone (WCAG 2.1.1, Level A). Every action achievable with a mouse must have a keyboard-equivalent. Hover-only menus must also open on keyboard focus.

No visible focus indicator

Barrier: CSS removes the default browser focus ring (outline: none / outline: 0) with no replacement — keyboard users cannot see where they are on the page.
Assistive Technology: Keyboard-only navigation
Design Consideration: Never remove the focus indicator without replacing it with a custom visible style. WCAG 2.4.7 (Level AA) requires focus to be visible. WCAG 2.4.11 (WCAG 2.2 Level AA) adds that focus must not be fully obscured by sticky headers.

Small click targets

Barrier: Tiny buttons, closely spaced links, and small form controls are difficult or impossible to activate with tremors, reduced precision, or eye-tracking input.
Assistive Technology: Head mouse, eye tracking, switch access
Design Consideration: Interactive targets should be at least 44×44 CSS pixels (WCAG 2.5.5 AAA). WCAG 2.2 adds 2.5.8 at Level AA requiring 24×24px minimum. Ensure adequate spacing between adjacent interactive elements.

Time limits without extension

Barrier: Session timeouts, timed quizzes, or limited booking windows expire before keyboard or switch users can complete the task — they navigate more slowly and need more time.
Assistive Technology: Keyboard, switch access
Design Consideration: Warn users before a time limit expires and allow them to extend it (WCAG 2.2.1, Level A). Exceptions include real-time events (live auctions) and security-essential timeouts — but even these should warn users before expiry.

Keyboard traps

Barrier: Focus enters a modal, widget, or embedded media player and cannot be escaped by keyboard — users are stuck and must reload the page.
Assistive Technology: Keyboard-only navigation
Design Consideration: Users must be able to move focus out of any component using the keyboard (WCAG 2.1.2, Level A). Modals should be closeable with Escape. If a custom key is required to exit, users must be told what it is.

Complex gestures without alternatives

Barrier: Swiping, pinching, multi-finger gestures, or path-based gestures (drawing shapes) are the only way to perform an action — users who cannot make these gestures are excluded.
Assistive Technology: Switch access, voice control, adaptive keyboards
Design Consideration: All functionality using multi-point or path-based gestures must have a single-pointer alternative (WCAG 2.5.1, Level AA). A horizontal swipe to dismiss must also have an 'X' button.

Drag-and-drop without alternative

Barrier: Reordering lists, moving files, or resizing panels requires click-and-drag — users with tremors or imprecision cannot perform sustained drag operations reliably.
Assistive Technology: Keyboard, voice control
Design Consideration: All drag-and-drop functionality must have an alternative mechanism (WCAG 2.5.7 in WCAG 2.2, Level AA). Examples: arrow keys to move items in a list, a 'Move to...' menu, or cut-and-paste metaphor.

Design considerations

Designer

Target size

Ensure all interactive elements are large enough to activate reliably:

Element type	Recommended minimum size
Primary buttons	44×44px (WCAG AAA best practice)
Navigation links	44px height minimum
Form controls (checkboxes, radios)	24×24px touch area (WCAG 2.2 AA minimum)
Icon-only buttons	44×44px — and add a text label
Adjacent interactive elements	At least 8px spacing between targets

Focus design

The focus indicator is the steering wheel for keyboard users. Design it deliberately:

Use outline or box-shadow — not background-color alone, which may not be visible on all surfaces
Minimum 3:1 contrast ratio between the focus indicator and adjacent colours (WCAG 2.4.11)
Make it at least 2px wide — thin 1px rings are often hard to see
Avoid shifting layout when focus is applied (don’t use margin changes)

Form design for motor disabilities

Group related fields together — reduce the number of Tab presses needed
Use appropriately sized form controls — the default browser checkbox is often too small
Provide clear, persistent labels (not placeholder-only labels that disappear on focus)
Autocomplete attributes reduce typing burden:

<input type="email" name="email" autocomplete="email" />
<input type="tel" name="phone" autocomplete="tel" />
<input type="text" name="given-name" autocomplete="given-name" />

Development considerations

Developer

Keyboard interaction patterns

Different interactive widget types have defined keyboard interaction patterns from the ARIA Authoring Practices Guide:

Widget	Expected keyboard behaviour
Menu / dropdown	Arrow keys to navigate items; Enter/Space to select; Escape to close
Modal dialog	Tab cycles within modal; Escape closes; focus returns to trigger on close
Tabs	Arrow keys to switch tabs; Enter/Space to activate
Accordion	Enter/Space to expand/collapse
Slider	Arrow keys to adjust value; Home/End for min/max
Date picker	Arrow keys to navigate calendar; Enter to select; Escape to dismiss

Provide a skip link at the very top of the page so keyboard users can bypass repeated navigation:

<a class="skip-link" href="#main-content">Skip to main content</a>

<!-- visible on focus -->
<style>
  .skip-link {
    position: absolute;
    top: -100%;
    left: 0;
  }
  .skip-link:focus {
    top: 0;
  }
</style>

Focus management in dynamic content

When content appears dynamically (modals open, panels expand, errors appear), move focus to the new content:

// When modal opens, move focus to it
modal.addEventListener('open', () => {
  modal.querySelector('[autofocus], h2, [tabindex="-1"]').focus();
});

// When modal closes, return focus to the trigger
modal.addEventListener('close', () => {
  triggerButton.focus();
});

Do not suppress all pointer events

Some implementations disable hover effects globally in response to prefers-reduced-motion, but this can inadvertently break interactive states for pointer users. Only suppress motion-causing transitions, not interaction states.

Testing keyboard accessibility

Complete keyboard walkthrough

Start at the top of the page (Ctrl+Home)
Tab through every interactive element — note the order
Every element must be reachable by Tab
Every element must show a visible focus ring
Every interactive element must be activatable with Enter or Space
No focus traps — you must be able to Tab off every element
Modals: focus must move into the modal and return to trigger on close
Dropdowns: must open on Enter, navigate with arrows, close on Escape
Skip link: first Tab press should reveal “Skip to main content”

Voice control test (Dragon or macOS Voice Control)

Enable Voice Control
Say “show numbers” — every interactive element should receive a number overlay
Say “click [element name]” for buttons/links — the accessible name must match what you would naturally say

Development Practices — complete keyboard and ARIA implementation guide
Testing and Evaluation — keyboard testing checklist
Design Principles — focus state design and target sizing