[mediaqueries-5] prefers-interaction-side media query & interaction-side property

[brandonmcconnell]

Introduction

This proposal introduces a new media query, prefers-interaction-direction, which allows web developers to adapt their layouts and user interfaces based on the user's preferred interaction direction. The media query informs the website about the optimal placement of interactive elements, such as login forms and navigation bars, to enhance user experience and accessibility.

This could be very helpful to users for several reasons:

• accessibility, supporting less able users
• right/left handedness-based preference/ability
• general/stylistic/usability preference

Syntax

The prefers-interaction-direction media query accepts the following values:

• left
• right
• top
• bottom

The media query can be used as follows:

@media (prefers-interaction-direction: left) {
  /* Styles for left-side interaction preference */
}

@media (prefers-interaction-direction: right) {
  /* Styles for right-side interaction preference */
}

@media (prefers-interaction-direction: top) {
  /* Styles for top-side interaction preference */
}

@media (prefers-interaction-direction: bottom) {
  /* Styles for bottom-side interaction preference */
}

Combining Interaction Directions

The prefers-interaction-direction media query allows for combining interaction directions to target specific user preferences.

For example, these two would be equivalent:

@media (prefers-interaction-direction: top right) {

@media (prefers-interaction-direction: top) and (prefers-interaction-direction: right) {

** These queries would target users with top-side and right-side interaction preferences set (independently checked, not corner-specific)

This feature enables web developers to create more tailored user experiences based on the combination of the user's preferred interaction directions.

Overriding the User Preference

To provide flexibility and control to web developers, a new CSS property, interaction-direction, is introduced to override the user's preferred interaction direction. This property functions similarly to the color-scheme property, which overrides the prefers-color-scheme media query.

.login-form {
  interaction-direction: right;
}

.login-form {
  /* Prevents the user agent from overriding the interaction direction for the element. */
  interaction-direction: only right;
}

The interaction-direction property accepts the same values as the prefers-interaction-direction media query, allowing web developers to explicitly set the interaction direction for specific elements.

/* Default value */
interaction-direction: normal;

/* Single-direction values */
interaction-direction: top;
interaction-direction: bottom;
interaction-direction: left;
interaction-direction: right;

/* Direction-paired values */
interaction-direction: top left;
interaction-direction: top right;
interaction-direction: bottom left;
interaction-direction: bottom right;

/* Global values */
interaction-direction: inherit;
interaction-direction: initial;
interaction-direction: revert;
interaction-direction: revert-layer;
interaction-direction: unset;

Any of the "Single-direction values" or "Direction-paired values" listed above could also be used with only to override default UA behavior.

One consideration is whether "Direction-paired values" should support only used once for both values or if it should be used per value as needed.

interaction-direction: only top left;
/* or */
interaction-direction: only top only left;

Prior Art

• Chrome (iOS only currently) allows users to choose whether to show the address/actions bar at the top or bottom. Similar to the color-scheme setting, which typically supports options: System Default/Light/Dark, apps could do the same with System Default/Top/Bottom or System Default/Left/Right, respectively. https://www.androidpolice.com/chrome-for-ios-bottom-bar-official/
• While X-axis-specific features are less common than Y-axis-specific ones, many applications and OS features also allow this as well, such as Adobe CC apps, Visual Studio, and Apple's Stage Manager and dock, allowing users to configure their preference between left/right options.

References and inspiration

• "The Thumb Zone: Designing For Mobile Users" by Samantha Ingram (Smashing Magazine, 2016):
  https://www.smashingmagazine.com/2016/09/the-thumb-zone-designing-for-mobile-users/
• "Bottom Navigation Pattern On Mobile Web Pages: A Better Alternative?" by Arturas Leonovas (Smashing Magazine, 2019):
  https://www.smashingmagazine.com/2019/08/bottom-navigation-pattern-mobile-web-pages/
• "How to design for thumbs in the Era of Huge Screens" by Scott Hurff (scotthurff.com, 2014):
  https://www.scotthurff.com/posts/how-to-design-for-thumbs-in-the-era-of-huge-screens/
• "Facebook Paper's gestural hell" by Scott Hurff (scotthurff.com, 2014):
  https://www.scotthurff.com/posts/facebook-paper-gestures/
• "One-handed mobile interface" by Konstantin Savchenko (Medium, 2015):
  https://konsav.medium.com/-55aba8ed3859
• "How Do Users Really Hold Mobile Devices?" by Steven Hoober (UXmatters, 2013):
  https://www.uxmatters.com/mt/archives/2013/02/how-do-users-really-hold-mobile-devices.php
• "Designing for Large Screen Smartphones" by Luke Wroblewski (LukeW Ideation + Design, 2014):
  https://www.lukew.com/ff/entry.asp?1927

Conclusion

The introduction of the prefers-interaction-direction media query and the interaction-direction property would empower developers to create more dynamically responsive and accessible user interfaces. By adapting to the user's preferred interaction direction, websites can enhance the user experience and cater to diverse user preferences and needs.

[tabatkins]

I presume this is related to the idea that, if you're holding a smartphone in your right hand, it's easier to access controls on the right and bottom sides, while top/left controls require either an uncomfortable reach or switching to using both hands?

If so, I definitely sympathize with the concern, and think there's potential here. However, is there any way to actually detect this? I'm not familiar with whatever APIs might exist. I know that the OSK can be switched to a mode that favors one hand or the other by shifting slightly to one side, but I only ever activate that by accident.

The big issue with new user-preference MQs is always going to be the actual detection. It can be the best idea in the world, but if no OS exposes that the user wants it (and the browser doesn't hack their own detection/preference-recording on top), we can't actually hang an MQ off of it.

[brandonmcconnell]

@tabatkins Thanks! Yeah, that's part of it, and to better support persons with disabilities.

Good call-out on the detection. My thought was to reach out to browsers as well and add support there first, and then work outward on getting that supported natively at the OS level, but perhaps I'm working backward here and should start OS-first.

[tabatkins]

I think this is one of the annoying cases that has to be worked at both ends simultaneously. :(

[brandonmcconnell]

Gotcha. I'll start reaching out to OS teams to see if I can gain some traction on that end. @argyleink recommended I reach out to Android OS to start, on Google's issue tracker.

[brandonmcconnell]

Related Android OS issue opened here: https://issuetracker.google.com/issues/336589276

[nattarnoff]

@brandonmcconnell Do you see this as a mobile only thing? Or are you expecting desktop users to use this? I ask for clarity. I think you have a good concept here, I'm just not sure of the execution of it.

One of the reasons is that while we've seen success with reflow for RWD, we still struggle to get developers to support orientation on native mobile apps. Considering these settings will have multiple variants we will need to convince designers as well. If the designers don't adopt flexible layouts, then this will go nowhere and I don't see them wanting to do this.

But the flexible layouts themselves may be an issue. If a site is coded with the navigation on top and the user sets it as preference for the bottom, what does the reading and focus order look like?

[brandonmcconnell]

@nattarnoff I've considered the same question.

While developers could use this in either desktop or mobile, I could see developers implementing this specifically for touch devices by combining prefers-interaction-direction with a pointer: coarse check, perhaps sometimes paired with a size query as well:

nav {
  position: fixed;
  top: 0;
}
form#login {
  float: left;
}

@media (pointer: coarse) {
  @media (prefers-interaction-direction: bottom) and (width < 767px) {
    nav {
      top: unset;
      bottom: 0;
    }
  }
  @media (prefers-interaction-direction: right) {
    form#login {
      float: right;
    }
  }
}

In terms of OS, prominent device companies like Google/Android and Apple would likely implement this feature exclusively on mobile and tablet devices, at least to start, unless the WCAG makes a solid argument to include it across all device types.

I see a case being made for less able persons preferring most interactions to be on one side of the screen to prevent having to move the cursor so far for every interaction. Many applications will inevitably be slow to adopt this, but providing a way for applications to hook into this preference would allow those companies and developers with ample bandwidth to cater to those specific needs, which would be a great convenience to those who need it.

Accessibility features like prefers-interaction-direction also have the potential to help companies and developers who use them. By removing unnecessary friction in the user journey, they can better serve their users and customers and increase their potential audience.

[AutoSponge]

I wonder if a better argument can be made for XR than for mobile. Maybe detection (e.g., Apple Vision Pro) is possible but maybe it's only stored in user preferences for the device to start with detection coming as hardware/OS expands sensors.

[brandonmcconnell]

@AutoSponge Interesting! I could see this being possibly helpful if implemented in XR/AR as well, though one of the primary use cases would be mobile as that addresses a common problem I and others face when crafting user interfaces.

[brandonmcconnell]

@nattarnoff Re designer/developer adoption, specifically your note on low orientation usage, I would make the argument that exposing that option does allow companies and developers to cater to that orientation when possible.

Adoption is important

The goal of implementing this feature, as with many accessibility issues, is to capture and expose the preference so designers/developers can tap into it.

The next journey will be adoption, which is an equally vital but arguably separate concern. Through education and social efforts, we can work to make these features—and others like them—ones that designers/developers will tap into.

TL;DR:

• We implement so designers/developers can use it.
• We educate so designers/developer will use it.

[brandonmcconnell]

But the flexible layouts themselves may be an issue. If a site is coded with the navigation on top and the user sets it as preference for the bottom, what does the reading and focus order look like?

@nattarnoff Reading order often remains unchanged when using features like this, and follows the flow of the order of elements in the DOM.

For example, the reading order of the content here remains "form ➞ main" regardless of their visually rendered order:

<div id="wrapper">
  <form id="login">…</form>
  <main>
    …
  </main>
</div>

#wrapper {
  display: flex;
}
main {
  flex: 1;
}

@media (prefers-interaction-direction: right) {
  main {
    order: -1;
  }
}

^{See example: https://codepen.io/brandonmcconnell/pen/NWmozxO/8b53be8b61fbb92d6223e1b70c3d9922}

[ByteEater-pl]

Why should top right be equivalent to separate occurrences with top and right? My first intuition was to interpret top and bottom as indicating preference for vertical progression of content following semantically (which is more common, and thus designers are taught to avoid horizontal scrolling more than vertical). So, top right would mean that interacting from top to bottom is preferred in the vertical direction, from right to left is preferred in the horizontal direction, but vertical arrangement is preferred as principal. The latter would be reversed with right top. Makes sense?

[brandonmcconnell]

@ByteEater-pl The problem this solves is less about the flow of content and more about which side of each axis a user prefers interactive elements to be on.

There would be no difference between top right and right top.

Here are some examples, one per axis:

• X (left/right) — login form on left vs. right side

  
  https://twitter.com/AdamFard_/status/1782733978786484237

• Y (top/bottom) — search bar on top vs. bottom side

  
  https://www.reddit.com/r/browsers/comments/1753u9h/top_search_bar_vs_bottom_search_bar_which_are_you/

There are rare instances I can think of where someone may want to query both axes together, so it may be more confusing to allow those to be queried together. This is certainly something I would like to collect more feedback on.

One example of why querying both together could be problematic is if someone queries both together to try to set up a corner-specific element without accounting for a use case where someone has no preference set on only one axis, which would be extremely common.

.corner-element {
  position: fixed;
  @media (prefers-interaction-direction: no-preference) { inset: auto 0 0 auto; }
  @media (prefers-interaction-direction: top left)      { inset: 0 auto auto 0; }
  @media (prefers-interaction-direction: top right)     { inset: 0 0 auto auto; }
  @media (prefers-interaction-direction: bottom left)   { inset: auto auto 0 0; }
  @media (prefers-interaction-direction: bottom right)  { inset: auto 0 auto 0; }
}

This is a non-issue if—like with prefers-color-scheme— we don't include a no-preference option, but I think including no-preference might be more valuable for prefers-interaction-direction as it may be considered a more impactful accessibility setting.

If the system default were bottom and right, apps might all start aligning content to cater to bottom and right preferences when, in most cases, this is not needed. With that in mind, users would enable this preference on a purely opt-in basis, and each axis would be set to no-preference by default.

In cases like the example above, it might be simpler to use one rule per axis:

.corner-element {
  position: fixed;
  @media (prefers-interaction-y: no-preference) or (prefers-interaction-y: bottom) {
    bottom: 0;
  }
  @media (prefers-interaction-y: top) {
    top: 0;
  }
  @media (prefers-interaction-x: no-preference) or (prefers-interaction-x: right) {
    right: 0;
  }
  @media (prefers-interaction-x: left) {
    left: 0;
  }
}

We can simplify further by setting defaults on the element styles itself, outside the queries:

.corner-element {
  position: fixed;
  bottom: 0;
  right: 0;
  @media (prefers-interaction-y: top) {
    top: 0;
    bottom: auto;
  }
  @media (prefers-interaction-x: left) {
    left: 0;
    right: auto;
  }
}

I anticipate most developers using prefers-interaction-direction this way.

It would still be vital to include no-preference as an option here, as it is very different from prefers-color-scheme, which deprecated the no-preference option.

[fantasai]

If this is about which side of the page interactive elements should be on, that's a very different thing from a "direction of flow" preference which is what this sounds like. Renaming; we can bikeshed more later but at least let's get the basic concept up front.

[brandonmcconnell]

@fantasai Thanks! Yes, I can see how that could be confusing. This is more about the interaction side, so that name sounds fine to me for now.

[matatk]

I'd like to mention an additional supporting use (particularly for including top and bottom) case I've come across for several years (partly as a vision-impaired person, but I think this generalises pretty well). We have had widescreen (and now even wider-screen) monitors for some time, and a lot of vertical screen space is wasted by things like toolbars that run along the top/bottom of apps. For me, this is exacerbated by my use of UI scaling to increase the size of UI controls and text - the wasted vertical space gets pretty big at times. I would love to be able to move some toolbars to the sides instead.

There are examples in some GUI environments where you can place things like taskbars/panels on the top/bottom or either side - far fewer extend this to general app toolbars too. Though some environments and applications let you position toolbars on any of the four sides. E.g. Inkscape (screenshots page) even automatically puts some toolbars on the left/right (rather than top/bottom) according to screen space, and it can position tool pallettes/docked windows on the left or right.

It would be great if mainstream operating systems and their standard GUI widget libraries would offer this flexibility, including for in-app toolbars. The web could leapfrog other platforms here. We discussed this on the Accessible Platform Architectures WG call today (thanks to @AutoSponge for the 'heads up' about this conversation), though this comment represents my personal (albeit I hope helpful as a datum point) perspective.