[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.

[frivoal]

I don't think the logical part of it is useful or works. mediaqueries work from the initial styles, so no amount of styling within the pages can change the mapping between logical and physical. Even if that did work, I have a hard time imagining users who hold their phone in the right hand when reading English, the left hand when reading arabic, and holding it from the top when reading vertical Japanese, so I don't think there's a need.

[brandonmcconnell]

@frivoal I agree completely. I was seeking validation on that, so thank you!

I'll remove that section to avoid confusion.

[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?