Most of the web is touch. We still don't save handedness.

How is there still no OS setting to save your handedness preference?

We can detect a surprising amount about how someone wants to use a page. Dark mode, reduced motion, higher contrast, reduced data: the prefers-* media features expose all of it. There is one obvious preference the platform never exposes: which hand you are using.

On a touchscreen, your hand is the interface. It is the cursor. Yet a designer building for that screen has no way to know whether the thumb in play is on the left or the right. So I opened a proposal with the CSS Working Group for a new media feature:

@media (prefers-handedness: left) {
  /* layout tuned for a left thumb */
}

@media (prefers-handedness: right) {
  /* layout tuned for a right thumb */
}

Like the rest of the family, this is a declared preference, not a guess about your body: the user sets it the way they set dark mode. And because it would live at the OS level, flipping it could be a one-tap control, the same quick toggle we already use for things like Bluetooth. The web already reflows an entire layout when you rotate the screen, so a left-to-right flip is a smaller version of a shift the platform has handled for years.

Here is why I think it earns a place in the family.

The case

Most of the web is touch now

Touch is no longer the secondary surface. As of Statcounter's May 2026 figures¹, mobile sits at 50.29% of global page views and tablets add another 1.48%. Phones alone have edged past desktop. The majority of the web now happens on a screen you hold in one hand and drive with the other.

And about 1 in 10 of those users are left-handed

The best estimate from the largest meta-analysis of handedness², 200 studies and over 2.3 million people, is that roughly 10% of people are left-handed. Stack that on top of a touch-majority web and you get a real population, not an edge case: a tenth of the dominant surface, using it the mirror image of how it was likely designed.

Apps already solve it, one at a time

This is not hypothetical. Creative apps already ship handedness settings by hand. Procreate has a Right-hand interface preference³ that flips its sidebar, because the default sits under the left hand while you paint with the right. SketchUp for iPad has a left-handed mode. Note apps tune palm rejection around which hand is resting on the glass. The mechanic differs (occlusion on a tablet, reach on a phone), but the missing signal is the same, and any of these apps could take its default straight from the OS instead of asking again.

Every one of these reinvented the same toggle, because the platform exposes no shared signal. That is the argument for standardizing one: a user should set this once and have everything honour it, not hunt for the same preference in every app. It is the same reason dark mode lives at the OS level instead of in a hundred separate settings screens.

It's a UX choice, and it goes beyond placement

Not just flipping the menu

To be clear, this is not "put the menu on the left." Designers already place navigation on either side freely, and both are fine. Which hand is holding the device is a different thing: a deliberate decision about what sits where, and that map depends on the hand. On a phone it is reach: a primary action belongs under the resting thumb, and a destructive action is often placed out of easy reach on purpose so it is hard to hit by accident. On a tablet it is occlusion: the dominant hand and forearm rest over the screen, so a control on the wrong side ends up under the very hand that is covering it. Without a handedness signal, that intent silently inverts for left-handers: the action you tucked away becomes the easiest one to hit, and the content you meant to keep clear sits under their hand. You never know it happened.

Gestures and interaction, not just layout

It also reaches past static layout. prefers-* features are readable from JavaScript through window.matchMedia, so handedness would drive interaction, not only styling:

const leftHanded = window.matchMedia("(prefers-handedness: left)").matches;

That opens up things CSS alone cannot reach: inverting a swipe or gesture direction, choosing which edge a swipe action lives on, deciding where a context menu opens so the hand does not cover it. This is an interaction signal, not a styling toggle.

The objections

"Too niche, too much work"

The feature itself is trivial: a single value a stylesheet or a script can read. The family already includes prefers-reduced-motion, which is more involved both to define and to honour, and it shipped. Dark mode is the cleaner precedent. prefers-color-scheme went from nothing to shipping across every major browser by early 2020⁴, fast, and it is arguably a more frivolous preference than how you physically hold the device. It is low-hanging fruit: easy to implement, and a real improvement for a substantial share of users. Hard to beat that return on effort.

"It needs platform buy-in"

True, and that is the point of proposing it as a standard. The signal would be an OS setting, the same origin as dark mode. Both prefers-color-scheme and prefers-reduced-motion needed operating systems to expose a setting, and both got it. Handedness only differs in that the toggle does not exist yet. The honest part: that is a heavier ask than a normal CSS feature, because it needs device makers, not just browsers. But the incentive is there. Handedness support is a real selling point on phones and tablets, and the stylus world already tracks it for palm rejection. The people who would benefit from shipping it are the same people who would ship it.

"It's a fingerprinting vector"

This is the serious objection, and it was the first thing raised on the proposal. The answer is to scope it. Handedness is meaningless on desktop, where the pointer is decoupled from grip, so the query can carry a value only in touch contexts and add no entropy where it would be useless anyway. And because it is a declared preference that ships off by default, like the rest of the family, it is a single low-entropy bit the user controls, not something inferred behind their back. It can also be restricted to first-party contexts, so the page you are visiting can read it but embedded third-party scripts cannot. That closes the cross-site tracking path without an opt-out checkbox or a permission prompt.

Weigh in

The proposal is live and open. If you have a use case, a concern, or a good argument against it, that is exactly what the thread is for: csswg-drafts #13215.

And if you think this should exist, say so there. A thumbs-up or a short comment with your own use case is the kind of signal that helps a working group tell a real need from a passing idea.