Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[mediaqueries] Suggestion: "prefers-pointer-location" #7872

Open
vimirage opened this issue Oct 12, 2022 · 6 comments
Open

[mediaqueries] Suggestion: "prefers-pointer-location" #7872

vimirage opened this issue Oct 12, 2022 · 6 comments
Labels
a11y-tracker Group bringing to attention of a11y, or tracked by the a11y Group but not needing response. i18n-alreq Arabic language enablement i18n-hlreq Hebrew language enablement i18n-tracker Group bringing to attention of Internationalization, or tracked by i18n but not needing response. mediaqueries-5 privacy-tracker Group bringing to attention of Privacy, or tracked by the Privacy Group but not needing response.

Comments

@vimirage
Copy link

vimirage commented Oct 12, 2022

(Firstly, I'm uncertain as to whether user suggestions are welcome here, or if they are preferred elsewhere. Feel free to redirect me!)

There is a small accessibility issue that makes using web pages on the internet marginally more difficult for left-handed mobile users: placement.

I am interested in specifically discussing how web pages often have "hamburger menus" on the right side, and how browsers have the scrollbars on the right side, among other key navigation elements.

A left-handed user on a mobile client will likely use their thumb to scroll on the page, or click items on the page. Therefore, in order to tap the scrollbar and drag down to any specific point on the web page, the user would have to move their (left!) thumb across the page - partially obscuring their view - to reach the scrollbar, then scroll, finally retracting to see the contents (, unless they're not at the place that they want to be at, in which case they'd have to repeat the process).

During a discussion elsewhere about this topic, it was suggested that a media query is proposed:

prefers-pointer-position: left | right | any;

As the example situation I described shows, the proposal here is intended to allow positioning elements efficiently for left/right handed users, as appropriate.

Another note, from @andreubotella, is that exposing this feature has privacy implications to consider, as it would reveal a client's hand dominance.

@frivoal frivoal added mediaqueries-5 i18n-tracker Group bringing to attention of Internationalization, or tracked by i18n but not needing response. a11y-tracker Group bringing to attention of a11y, or tracked by the a11y Group but not needing response. privacy-tracker Group bringing to attention of Privacy, or tracked by the Privacy Group but not needing response. labels Oct 24, 2022
@frivoal
Copy link
Collaborator

frivoal commented Oct 24, 2022

Firstly, I'm uncertain as to whether user suggestions are welcome here, or if they are preferred elsewhere

This is the right place, and feedback is absolutely welcome. Do note that due to the amount of discussions ongoing on so many topics, it can take quite some time before you get a response by someone.

@JoshuaLindquist
Copy link

Could this idea be expanded to obscure privacy concerns?

Preferring the placement of "hamburger menus" on the left or right or preferring the placement of scroll bars on the left or right does not necessarily reveal a dominant hand, but targeting other page design features could remove the means to pinpoint the private information.

There are other page design preferences that can be tied to these decisions as well. Generally speaking, it is easier to hit navigational buttons with your thumb when they are along the bottom of the screen, but I strongly dislike that placement and prefer the navigation to be at the top of the page. What if we had a media query that could adapt pages for those preferences?

That could change your values from just left and right to top left or bottom right, among others.

We can reframe the media preference as about a personal choice (like light or dark mode) instead of being strickly about your dominant hand. It still solves the accessibility problem.

This does sort of snowball the idea into multiple queries and/or many values. What if you want the "hamburger menu" on the left, the scroll bars on the right, and the nav bar at the bottom? That's now 3 different features.

I think this is worth exploring. It would be a valuable design addition to make websites work according to user preferences without the need for a custom settings panel to toggle these on and off (again, similar to prefers-color-scheme).

@vimirage
Copy link
Author

vimirage commented Nov 1, 2022

Could this idea be expanded to obscure privacy concerns?

Sure! Although it may be worth weighing how this, as you say, does not definitely reveal dominance. Technically even preferring dark mode can reveal a light sensitivity?

Preferring the placement of "hamburger menus" on the left or right or preferring the placement of scroll bars on the left or right does not necessarily reveal a dominant hand, but targeting other page design features could remove the means to pinpoint the private information.

There are other page design preferences that can be tied to these decisions as well. Generally speaking, it is easier to hit navigational buttons with your thumb when they are along the bottom of the screen, but I strongly dislike that placement and prefer the navigation to be at the top of the page. What if we had a media query that could adapt pages for those preferences?

Personally, I think many pages would be fine simply mirrored vertically (such as putting images/buttons/text on the opposite sides), for users with a left-sided preference. That can be handled with a navigation element side preference. Yet this doesn't address your more general request.

That could change your values from just left and right to top left or bottom right, among others.
We can reframe the media preference as about a personal choice (like light or dark mode) instead of being strickly about your dominant hand. It still solves the accessibility problem.

This does sort of snowball the idea into multiple queries and/or many values. What if you want the "hamburger menu" on the left, the scroll bars on the right, and the nav bar at the bottom? That's now 3 different features.

I think this is worth exploring. It would be a valuable design addition to make websites work according to user preferences without the need for a custom settings panel to toggle these on and off (again, similar to prefers-color-scheme).

One issue about this is that it becomes so much more complicated, that I fear it could discourage practical use and implementation. With {left, right, none} × {top, bottom, none}, along with an unspecified/any/default, that's 9 enumerations. How many web developers would even consider handling so many cases, for the presumably marginal amount of users who prefer anything other than the web page author's default?

@dbaron
Copy link
Member

dbaron commented Nov 1, 2022

One thing I would caution is that I think we should avoid suggesting that it's a good idea to use a phone's touchscreen with the thumb of the same hand you're holding the phone with. I ended up with tendonitis in my thumb/hand as a result of doing that (which was briefly bad enough that I had trouble with some basic tasks like using doorknobs and washing dishes), and I didn't realize it was due to phone usage until I started telling my doctor about it -- and my doctor was able to correctly diagnose the problem within about 15 seconds of when I started telling him about it, and suggested it was pretty common. I've completely avoided recurrence by making sure to use the touchscreen with a different hand than the one holding the phone.

@vimirage
Copy link
Author

vimirage commented Nov 1, 2022

@dbaron I personally fully understand and agree; I have reviewed medical perspectives of phone ergonomics and common use, and seen that this poses danger too.

Thank you for raising the concern, it is frequent and I do hope that would be considered here.

@lwolberg
Copy link

lwolberg commented Nov 2, 2022

We would like to hear from i18n on this, as it relates strongly to RTL/LTR.

@xfq xfq added i18n-alreq Arabic language enablement i18n-hlreq Hebrew language enablement labels Nov 4, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
a11y-tracker Group bringing to attention of a11y, or tracked by the a11y Group but not needing response. i18n-alreq Arabic language enablement i18n-hlreq Hebrew language enablement i18n-tracker Group bringing to attention of Internationalization, or tracked by i18n but not needing response. mediaqueries-5 privacy-tracker Group bringing to attention of Privacy, or tracked by the Privacy Group but not needing response.
Projects
None yet
Development

No branches or pull requests

6 participants