Acceleration must be disableable

What it is

“Acceleration must be disableable” means a system using velocity-dependent pointer mapping should let people restore fixed gain. It accommodates different tasks, devices, accessibility needs, and learned motor skills; it does not require everyone to turn acceleration off.

Why it happens

Acceleration applies one mapping assumption to every action, though control strategies and tasks differ. Some benefit from faster long-distance transport; others rely on constant mapping for drawing, games, remote control, or motor-impairment compensation. A switch lets people select the function matching their feedback loop rather than forcing an optimisation for one task onto another.

For someone with tremor or limited motor control this is not just a preference: because acceleration scales gain with instantaneous speed, one involuntary fast jerk gets amplified into a proportionally larger screen displacement; under fixed gain the same jerk produces only a fixed-size deviation that later movement can correct more easily. Acceleration, in other words, is not merely "not as good" for this group — it systematically amplifies exactly the motor noise they already have to manage, which is why disableability belongs on the accessibility-requirement side of the line, not the optional-preference side.

Where it stops holding

Disableable does not mean burying an option in a developer menu, nor may an application override a system preference and reactivate acceleration. Managed devices or specialised hardware can restrict settings, but should state the active mapping and offer alternate input where possible. Updates and reconnections must not silently reset the choice.

A common, concrete failure is an application building its own acceleration on top: some game engines, drawing applications, and remote-desktop clients still apply a velocity-dependent resampling or smoothing step inside their own input handling even when system-level acceleration is off. The user's settings say "disabled"; the curve they actually feel has not changed. Devices under centralized management can also lock pointer settings through policy — a restriction that should be visible to the user, not silently in effect.

Applying it

• Provide a clear acceleration switch in a discoverable system or application setting, stating which input it affects.
• Respect the system pointer preference; do not silently override it in canvases, games, or remote sessions.
• Include the switch state in regression testing across restart, hot-plug, and configuration synchronisation.
• Capture a baseline displacement-to-output curve, recording output displacement for the same set of physical displacements before and after acceleration is disabled, to confirm the application layer is not applying its own curve underneath.

Related

• Same group: C1.04.1 Acceleration dynamically changes gain with movement speed · C1.04.2 Acceleration disrupts a stable device-to-screen mapping · C1.04.3 Acceleration is a net loss for tracing and drawing
• Nearby: C1.03 Control-display gain · J1 Motor and interaction accessibility
• Search terms: disable pointer acceleration · fixed gain · input preference