Skip to content
All updates
4 min read

Building Cursor for Disabled

Notes from building an adaptive cursor system — why the mouse is a hidden gatekeeper, and what it takes to make precise pointing a solved problem for any body.

  • projects
  • assistive software
  • computer vision

Most people never think about the cursor. You move your hand, the pointer moves, you click. It is so automatic that it feels less like using a tool and more like having a limb. That invisibility is exactly what makes it dangerous as a piece of design — because for a large number of people, that limb does not work the way the software assumes.

Cursor for Disabled started from a simple observation: before you can use almost any modern computer, you have to win a game of precision pointing. And that game quietly excludes anyone whose hands shake, whose range of motion is limited, who has paralysis, or who simply cannot hold a mouse steady. The cursor is the first gate, and millions of people never get through it.

The problem is the assumption, not the ability

It is tempting to frame this as a problem of people who cannot use a mouse. I think that framing is backwards. The problem is a mouse that assumes steady, precise, continuous hand movement — an assumption baked so deep into interfaces that we forgot it was a choice.

Once you see it as an assumption, the design space opens up. The question is no longer "how do we help people use a mouse?" It becomes "what is the smallest, most reliable way to express I want to point there and act on it — using whatever input this person actually has?"

That person's input might be:

  • A small, residual hand motion with a lot of tremor.
  • Head movement tracked by a camera.
  • A single switch they can press with a finger, foot, or cheek.
  • Eye gaze with dwell.

The job of the software is to take any of these and turn it into accurate, confident pointing.

What the engine actually has to do

Under the hood, three problems matter more than anything else.

Smoothing without lag. Tremor and noise have to be filtered out, but naive smoothing introduces lag, and lag makes a cursor feel like it is wading through syrup. The trick is adaptive filtering: smooth aggressively when the user is holding still or making fine adjustments, and get out of the way when they make a deliberate, fast movement. The cursor should feel calm, not sluggish.

Forgiving targets. A 24-pixel button is brutal if you cannot land within 24 pixels. So the engine reasons about intent: as the cursor approaches a likely target, it gently assists — a soft gravity toward clickable things, expanded effective hit areas, and acceleration curves tuned for control rather than speed. The user does not have to be precise; the system meets them partway.

Clicking without clicking. For many users, the click is harder than the movement. Dwell-clicking — hold the pointer still over a target for a moment and it activates — removes the need for a separate button press entirely. The hard part is tuning the dwell so it does not fire by accident while someone is just resting.

The constraint that shaped everything: ordinary hardware

The single most important design decision was this: it has to run on hardware people already own.

There is a whole world of excellent assistive technology that costs thousands of dollars and requires specialist setup. It is genuinely good, and it reaches almost no one, because most people who need it cannot afford it or cannot get it prescribed and configured. Technology that only works in a lab or a clinic has, in practice, decided who it is for.

So Cursor for Disabled targets a regular laptop with a regular webcam. No special sensors required, though it can use them if they exist. That constraint made the engineering harder — webcam-based tracking is noisier than dedicated hardware — but it is the difference between a research demo and a tool someone can actually start using tonight.

What I keep learning

The most humbling part of this work is how often I am wrong about what will help. I have shipped features I was certain about that testers quietly never used, and small details I almost cut that turned out to be the thing that made the whole system click for someone.

So the loop is the real product: build a little, put it in front of real people, watch closely, and let what actually happens overrule what I assumed would. The cursor is just code. Whether it gives someone back the ability to use their own computer, independently — that only the people using it can tell me.

That is the part I am building toward. Everything in the codebase is in service of it.

Keep reading