The left button carries primary selection, with nearly universal platform semantics

What it is

The left mouse button normally carries primary selection, activation, confirmation, and drag initiation. Although systems can swap buttons, it is the most stable primary-button convention across desktop platforms and applications; people expect a click to select or open an object without learning first.

Why it happens

What the driver layer actually maintains is an abstract primary button flag, not "whichever button sits on the left" — click, double-click, and drag are all interpreted on top of that abstraction. This is a deliberate design: it lets the operating system reassign "primary" to the physical right button in settings without touching any application's logic, as long as applications faithfully listen for the primary-button event rather than testing "is this the left one" themselves. Keeping that layer of indirection stable is what lets people build durable muscle memory and transfer it across applications; the moment a product misroutes its main action to a non-primary button, people act on the old convention out of habit and get it wrong.

Where it stops holding

Left is a common default, not a biological necessity: left-handed users can set the physical right button as primary in system settings, and trackpads or touchscreens need not have a physical left button at all. What should remain stable is primary-selection semantics and its configurability, not requiring everyone to press the same physical side. There is a concrete engineering trap here: in some browser-and-OS combinations, even after a user has set the physical right button as primary at the system level, the MouseEvent.button value the web page receives is swapped accordingly in some environments but still numbered by physical position in others — code that checks "is button equal to 0" instead of relying on the system's already-resolved primary-button semantics will draw the wrong conclusion on a left-handed user's machine.

Applying it

• Bind core selection and activation to the platform's resolved primary-button event, not a hard-coded physical left button or a fixed button index.
• Preserve system primary/secondary swapping; say "primary click" or "click" rather than assuming handedness.
• Use extra buttons for discoverable acceleration, never as the only basic route.
• How to check: switch the system-level primary button to the physical right button, then walk through the product's core selection, activation, and drag flows again to confirm nothing quietly followed the physical left button instead.

Related

• Same group: 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 · C1.21.5 Functions bound only to non-left buttons are unavailable to one-button-mouse and trackpad users
• Nearby: C1.22 Drag thresholds and intent classification · E1 Interface elements and controls
• Search terms: primary button · selection · mouse