Designing for Motor Accessibility: It's More Than Just the Mouse

As designers, let's be honest, motor or physical disabilities rarely lead the conversation when we discuss WCAG or 508. As we've discussed previously, vision gets the spotlight, hearing gets a nod, and we sometimes forget to think about motor accessibility early in design, if at all.

That's a problem, and the numbers tell a story worth paying attention to.

According to the CDC, approximately 13.7% of U.S. adults have some form of motor disability. This includes people who may not be able to use a mouse, navigate a touchscreen with precision, or interact with your course the way you assumed they would when you built it.

So let's talk about what motor accessibility actually requires, and what it looks like in practice.

Who Are We Designing For?

Motor and physical disabilities cover a wide range of conditions. We're talking about people with limited hand or arm mobility, tremors, paralysis, repetitive strain injuries, and conditions like cerebral palsy, multiple sclerosis, or arthritis. We're also talking about people recovering from temporary limitations (surgery, injury) that are just as real while they're happening.

Then there's the situational piece. A learner holding a phone on a crowded train. Someone with a broken wrist finishing a required compliance module. A worker in a warehouse who can't interact with a touchscreen while wearing gloves.

Motor accessibility doesn't just serve people with permanent disabilities. It serves anyone whose physical interaction with a device is limited in any way at any given moment.

The Big Four for Motor Accessibility in eLearning

1. Keyboard Navigation - the Non-Negotiable

This is the foundation of motor accessibility. Learners who can't use a mouse rely on keyboard navigation to move through your course. That means every button, every interaction, and every piece of content needs to be reachable and operable using only a keyboard.

Tab to move forward. Shift+Tab to move back. Enter or space to activate. Arrow keys to select. If your course doesn't support that flow cleanly, a significant portion of your learners are stuck.

Designer Hint: Test your course with your mouse unplugged. Every single slide. If you can't complete the course using only a keyboard, neither can your motor-impaired learners. In Articulate Storyline, keyboard navigation is supported by default, but your tab order and interactive element setup still need to be intentional. Don't assume the defaults are correct.

2. Logical and Predictable Tab Order

As we discussed in the blog on visual accessibility, keyboard navigation only works if the tab order makes sense. If a learner tabs through your slide and the focus jumps randomly from a button in the lower right to a header at the top left to a decorative image in the middle - that's not navigation, that's a maze.

Tab order should follow the natural reading flow of the content: left to right, top to bottom, logical and predictable. Decorative elements should be excluded from the tab order entirely so they don't interrupt the flow.

Designer Hint: In Articulate Storyline, set your tab order manually in the tab order panel on every slide. Don't rely on the default order, which is based on when objects were added to the slide rather than where they sit visually. This one fix alone makes a significant difference.

3. Selectable Target Size and Spacing

This one gets missed constantly. Small buttons and tightly packed selectable elements are a problem for anyone with limited dexterity, tremors, or reduced precision. If your learner has to select an exact 12-pixel target to advance the course, you've already created a barrier.

WCAG 2.1 recommends a minimum target size of 44x44 pixels for interactive elements. Spacing between selectable items also matters - accidental selections on the wrong element are more than an annoyance when a learner has limited motor control.

Designer Hint: When in doubt, make it bigger. Buttons, navigation arrows, and interactive elements should all be large enough that a learner doesn't need precision to activate them. If your design feels cramped, that's a signal worth acting on. Remember, hotspots are not usually recommended for ease of accessibility.

4. No Time Limits on Interactions

Timed interactions are one of the most common motor accessibility failures in many learning courses - from childhood to adulthood. Timed tests. Drag-and-drop activities with countdown timers. Click-to-reveal sequences that auto-advance. Scenarios that require rapid responses.

For a learner who navigates slowly due to a physical disability, a time limit isn't a challenge - it's a wall. WCAG 2.1 requires that users can turn off, adjust, or extend any time limit unless it's essential to the content itself.

We will discuss this topic more in an upcoming blog on how this impacts learners with many hidden disabilities as well.

Designer Hint: Unless a time constraint is genuinely central to the learning objective (and it rarely is), remove it. If you keep a timer, provide a clear and accessible way to pause or extend it. Ask yourself honestly: does this learner actually need to complete this in 30 seconds, or does that just feel more engaging to you as a designer?

This is also where, as the expert, you may need to speak up and state the reasoning why we don't like to include timed activities when asked to design them. We are the only ones in the room whose number one priority is the learner.

A Note on Drag-and-Drop Activities

Drag-and-drop interactions are popular in eLearning because they feel interactive and engaging. They're also one of the least accessible interaction types available.

For keyboard-only users, drag-and-drop often doesn't work at all. For users with tremors or limited precision, it's frustrating even if it technically functions.

If you use drag-and-drop, always provide a keyboard-accessible alternative - a dropdown menu, a matching activity, a selectable option. The interaction type should serve the learning, not the other way around.

Designer Hint: Storyline drag-and-drop activities are NOT WCAG or 508 compliant without extensive variable and trigger builds. If you do build one, ensure you test it for passage of all accessibility requirements.

A Note on Virtual and Classroom Design

Motor accessibility doesn't stop at eLearning. If you're designing virtual or in-person instructor-led training, the same thinking applies.

Breakout room activities that require rapid typing. Whiteboard exercises that depend on mouse precision. Physical activities in a classroom that assume full range of motion. Any activity where participation requires a specific motor skill - and there's no alternative path - is an activity that excludes someone.

The fix isn't to remove the activity. It's to build in an alternative from the start. A learner who can't drag items on a virtual whiteboard should be able to contribute verbally or through a chat-based option. A classroom exercise that involves physical movement should have a seated or limited-mobility alternative that still achieves the same learning objective.

Think about it the same way you would an eLearning interaction. Ask yourself: if a learner can't do this the way I designed it, can they still achieve the outcome? If the answer is no, you have a design problem - not a learner problem.

What Good Looks Like

Motor accessibility isn't about removing interactivity from your courses. It's about building interactivity that works for everyone - regardless of how they're physically navigating the content.

Done well, it doesn't just serve learners with physical disabilities. It makes your courses cleaner, more navigable, and more usable for every learner on every device.

What motor accessibility tips or workarounds have you found most useful in your builds? Drop them in the comments.