Functions bound only to non-left buttons are unavailable to one-button-mouse and trackpad users

What it is

When a function is bound only to middle, right, or side buttons, users with one-button mice, simplified trackpads, keyboards, or assistive input may be unable to invoke it at all. Non-primary-button-only binding turns hardware contingency into an access barrier, particularly for basic navigation, confirmation, and editing.

Why it happens

Input devices already differ in button count and gesture support; an operating system may emulate right click with a hold, a two-finger tap, or a key chord, or may not offer that emulation path at all. But a deeper problem sits with certain assistive devices: single-switch scanning devices, and some head-pointing or eye-gaze input setups, are structurally capable of producing only one kind of "confirm" event — there is no physical channel to generate a second or third distinct button signal. This is not a missing configuration; it is how these input devices fundamentally work, and no amount of operating-system or application accommodation can add a channel that the hardware never had. If an application welds a key function to right-click or a side button with no equivalent command exposed, that function is not merely inconvenient for this population — it is structurally unreachable.

Studying it

Create a function-to-input-path matrix covering one-button mice, trackpads without side buttons, keyboards, touchscreens, and common single-switch or head-controlled assistive devices. Have people complete critical tasks and record which steps are entirely unreachable and how long it takes to discover an alternative for the rest; do not sign off using a developer's fully equipped multi-button mouse, since that device itself hides the problem.

Where it stops holding

Extra buttons can remain efficient accelerators; the issue is never supporting them, only when they are the sole route to a function. A specialist, controlled-hardware setting — an internal tool that explicitly requires a specific mouse model, say — can narrow the set of alternatives, but that deployment premise needs to be stated explicitly and never assumed as the default for a general-audience product. A product meant for the public should fully decouple its basic functions from any particular mouse model.

Applying it

• Give every core command a primary-click visible entry, a keyboard route, or a touch equivalent; no critical path should depend solely on right-click, middle-click, or a side button.
• Treat right and side buttons as supplemental accelerators, and actively surface a discoverable alternative when they are unavailable, rather than letting the function quietly disappear.
• How to check: take a device that can genuinely produce only a single confirm signal — a single-switch scanning input or the most basic one-button mouse — and walk the entire core task flow through to completion; any step that cannot be completed reveals a function bound exclusively to a non-primary button.

Related

• Same group: C1.21.1 The left button carries primary selection, with nearly universal platform semantics · C1.21.2 Middle-button semantics vary by application and lack a unified convention · C1.21.3 Side-button back and forward mappings depend on drivers and are not system-guaranteed · C1.21.4 Efficiency gains from more buttons depend on remembering nonstandard mappings
• Nearby: C1.01 Types and properties of pointing devices · A1 Human capabilities and human-factors foundations
• Search terms: input accessibility · one-button mouse · trackpad