A11.07.4Offering interface mirroring and a handedness settingdesign

Letting users mirror the layout or set their handedness fixes what defaults get wrong

Aliases: handedness preference · left-handed mode · mirrored layout

What it is

Occlusion direction, reach zone, and palm-rejection judgment all shift direction with handedness, and together they point at the same design decision: whether to give users a handedness preference that lets hand-position-dependent parts of the layout mirror left to right. This leaf is about how that setting itself should be positioned, where it lives, and what it mirrors — not a re-explanation of why any one mechanism shifts with handedness.

Why it happens

Any single fixed default layout can only serve one handedness, leaving the other to compensate on its own — the setting exists precisely to shift the burden from "the user compensates" to "the system adapts." But mirroring isn't free: mirroring content that has nothing to do with hand position along with everything else disrupts muscle memory and reading habits users bring from other apps and contexts, creating a new inconsistency instead of removing an old one. What should actually be mirrored is limited to elements whose layout is driven by hand-approach direction, reach arc, or grip — content order and reading flow that have nothing to do with hand position shouldn't be flipped along with them.

Where it stops holding

A mirroring setting only matters for elements whose layout is genuinely driven by hand position. If an interface's frequent actions aren't concentrated to one side to begin with (a two-handed tablet grip, for instance), the benefit of a mirror toggle is limited and doesn't justify the added cognitive overhead of another setting. Full-screen mirroring and mirroring only the hand-related controls are also two different trade-offs: the former is simple but breaks consistency with other apps; the latter is more precise but harder to implement. Which to choose depends on how large a share of the interface is actually hand-position-driven.

Applying it

  • Mirror only the components whose layout is driven by hand position, reach arc, or grip (side-mounted action zones, one-handed-reach controls) — leave content order, reading flow, and other hand-independent elements unmirrored.
  • Put the handedness setting where users configure preferences related to physical interaction, not buried inside a generic settings category unrelated to hand operation; offer a quick handedness prompt at first use rather than requiring the user to dig through settings on their own.
  • Verification: have left-handed users complete the same set of one-handed tasks with mirroring on and off, and compare completion time and error rate. A clear gap closing when mirroring is on confirms the mirroring is actually taking effect; no change in the gap means the wrong set of components was mirrored.

Related

  • Same group: A11.07.1 Left-handed prevalence and the cost of being ignored by default
  • Adjacent: S1.02 Mirroring for right-to-left languages
  • Search terms: handedness preference · mirrored layout · left-handed mode

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/A11.07.4