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

Use case (author / website visitor): Require interaction before allowing pan/zoom #180

Open
Malvoz opened this issue Sep 25, 2019 · 7 comments
Labels
discussion: use case a possible use case: should it be included? what should it say? section: map viewer Capabilities & use cases for declarative map viewer widgets status: editor's draft there's a draft section in the report that corresponds to this discussion

Comments

@Malvoz
Copy link
Member

@Malvoz Malvoz commented Sep 25, 2019

This issue is for discussion of the use case “Require interaction before allowing pan/zoom”, its examples & list of required capabilities.


When a user hovers their mouse pointer (even if just briefly) over a map, before wanting to continue scrolling the web page (or panning the screen, on touch devices) map viewers are often panned/zoomed instead, sort of trapping the user from scrolling.

Maybe there should be a way for authors, or perhaps the end-user even, to dictate whether panning/zooming should be allowed before interacting with it, such as tapping/clicking the map.

Of all the reviewed reference tools, Google Maps is the only one to require interaction (see Google Maps' "Cooperative Gesture Handling") before enabling pan/zoom - requiring using 2 fingers to interact with the map on touch devices, or holding ctrl + mouse pointer interaction on desktop (Windows).

(Similar issues could arise from <iframe> already, or any overflowing element, maybe this should be a WHATWG HTML issue instead.)

@Malvoz Malvoz added discussion: use case a possible use case: should it be included? what should it say? status: suggestion this issue discusses a suggested addition to the report, that is not yet in the draft labels Sep 25, 2019
@prushforth
Copy link
Member

@prushforth prushforth commented Sep 26, 2019

When a user hovers their mouse pointer (even if just briefly) over a map, before wanting to continue scrolling the web page (or panning the screen, on touch devices) map viewers are often panned/zoomed instead, sort of trapping the user from scrolling.

This is about the most annoying feature of in-page web maps that I can think of.

Maybe this relates to "static maps" (somehow, just thinking out loud), in that the layers of the map could be designated static, and an event handler could release them. The handler could be on a (visual) control or affordance.

Of all the reviewed reference tools, Google Maps is the only one to require interaction before enabling pan/zoom - requiring using 2 fingers to interact with the map on touch devices, or holding ctrl + mouse pointer interaction on desktop (Windows).

I've read criticism of that, but I don't know why.

@Malvoz
Copy link
Member Author

@Malvoz Malvoz commented Sep 29, 2019

@prushforth

It may feel unintuitive, and especially awkward using 2 fingers while only holding the device in one hand. But I think it's still better than not requiring interaction first, for the reasons mentioned.

@Malvoz Malvoz changed the title Use case (author / website visitor): Require interaction before allowing pan/zoom in the map viewer Use case (author / website visitor): Require interaction before allowing pan/zoom Oct 7, 2019
@Malvoz Malvoz added the section: map viewer Capabilities & use cases for declarative map viewer widgets label Oct 7, 2019
@Malvoz Malvoz added status: editor's draft there's a draft section in the report that corresponds to this discussion and removed status: suggestion this issue discusses a suggested addition to the report, that is not yet in the draft labels Jan 25, 2020
@Malvoz
Copy link
Member Author

@Malvoz Malvoz commented Mar 29, 2020

Of all the reviewed reference tools, Google Maps is the only one to require interaction

Actually, MapKit does require holding ctrl on Windows desktop to zoom using the mouse wheel, however no interaction is required on Android.

@shepazu
Copy link
Member

@shepazu shepazu commented Nov 18, 2020

“3.1.12 Require interaction before allowing pan/zoom (or opt-out of such potentially default behavior)” needs to be reformulated as a use case. it’s currently described in terms of a requirement.

As described, it doesn’t have any capabilities listed (perhaps since it is itself a capability).

@zcorpan
Copy link

@zcorpan zcorpan commented Nov 22, 2021

This section's description doesn't seem to match with the behavior of a Google Maps embed. It's not that there is a requirement of interaction before allowing zooming. It's that there is a modifier (hold ctrl while scrolling, or use two fingers) to zoom, so as to not clash with page scrolling.

The current wording suggests that after you have interacted, you can zoom without the modifier. But that is not the case.

@Malvoz
Copy link
Member Author

@Malvoz Malvoz commented Dec 7, 2021

@shepazu

it’s currently described in terms of a requirement

The use case is the requirement of an interaction/modifier to allow further interactions with the map. Maybe I'm misunderstanding your comment?

@zcorpan

This section's description doesn't seem to match with the behavior of a Google Maps embed.

I think I didn't want to assume a standardized map viewer would behave exactly like Google Maps. Perhaps the heuristics would be smarter, the Google Maps modifier is sometimes challenging to get past, especially so using TalkBack. I'm happy to change the title, if only by replacing the word "interaction" with "modifier"?

@zcorpan
Copy link

@zcorpan zcorpan commented Dec 22, 2021

@Malvoz sure, I didn't mean the standard should match Google Maps, only that Google Maps seems to solve the same problem but without keying off of "interaction", and that also seems like a valid approach.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion: use case a possible use case: should it be included? what should it say? section: map viewer Capabilities & use cases for declarative map viewer widgets status: editor's draft there's a draft section in the report that corresponds to this discussion
Projects
None yet
Development

No branches or pull requests

4 participants