Capability: Pan the map display

[Malvoz]

This issue is for discussion of the required map viewer capability “Pan the map display”.

[Malvoz]

Side-by-side/grouped controls for panning take up a lot of space in the map viewer, perhaps that is why none of the reviewed tools provide such controls (by default at least). Another consideration could be "border pan" controls, which is part of a recommended layout in the research paper "Accessible Web Maps for Visually Impaired Users: Recommendations and Example Solutions":

Although they go as far as to say "Interaction tools (e.g., for zooming and panning, or selectors for basemaps and overlays) should be located outside the map component. They should not cover parts of the map". But it's sort of the convention to overlay interaction tools on the map display, I believe that by ensuring a certain level of contrast and/or properly respond to user preferences for high contrast they can be made just as accessible.

[prushforth]

Pan controls have more or less disappeared from modern web maps. For keyboard access, the pan controls seem to interfere with using the arrow keys, if they're focused, meaning you have to tab between them to adjust the map location in a different direction. Maybe we should support a focus ring on the whole map for the map when it can be panned/zoomed by the arrow keys? I believe it should be possible, in a standard map widget, to turn controls off and provide your own, for example putting controls outside the map extent. I realize that may not be the best approach to default accessibility, depending on how compelling the reasons are for creating them by default. Thoughts?

[Malvoz]

Pan controls have more or less disappeared from modern web maps.

It'd be interesting to get some insight to why that is. Google Maps deprecated their pan controls in 2015 (although they remain available in Street View). Were they common at some point?

For keyboard access, the pan controls seem to interfere with using the arrow keys, if they're focused, meaning you have to tab between them to adjust the map location in a different direction.

As I understand it, the arrow keys are shortcuts for the "map component" (usually a focusable container that encompasses all the components), and as such should not be available when the pan controls are focused, per WCAG guidelines (SC 2.1.4 Character Key Shortcuts):

• Active only on focus: The keyboard shortcut for a user interface component is only active when that component has focus.

so that's seemingly the desired behavior.

Maybe we should support a focus ring on the whole map for the map when it can be panned/zoomed by the arrow keys?

This is the "map component" described above. Most (not all) of the reviewed tools have a focusable container, and when focused, arrow keys to pan are made available to the user. Is such functionality sufficient to meet the needs of "all" users to be able to pan the map display? Is it feasible to meet "all" users' needs? We need accessibility experts (and maybe user research) to help inform with this.

I believe it should be possible, in a standard map widget, to turn controls off and provide your own, for example putting controls outside the map extent. I realize that may not be the best approach to default accessibility, depending on how compelling the reasons are for creating them by default.

I think visible controls are mostly useful for users who cannot perform drag/swipe gestures (and who also do not have access to a keyboard, whether physical or virtual?), the requirement of WCAG SC 2.5.1 Pointer Gestures is:

All functionality that uses multipoint or path-based gestures for operation can be operated with a single pointer without a path-based gesture, unless a multipoint or path-based gesture is essential.

[prushforth]

We need accessibility experts (and maybe user research) to help inform with this.

@shepazu @AmeliaBR @nchan0154 wdyt?

[nchan0154]

I think visible controls are mostly useful for users who cannot perform drag/swipe gestures (and who also do not have access to a keyboard, whether physical or virtual?),

Not quite an expert and haven't done any user research (which is very advisable in this case, uncharted territory and all that), but I think one of the main reasons why 2.5.1 Pointer Gestures exists is because mobile screen reader users (users on Android or iOS, essentially) use touch/gesture based controls to control the screen reader, and having a map control (panning) be only activatable via keyboard or gesture is problematic for these users. It's worth noting that an alternative to the pinch to zoom gesture is specifically called out as being a good practice on this success criterion page.

A web site includes a map view that supports the pinch gesture to zoom into the map content. User interface controls offer the operation using plus and minus buttons to zoom in and out.

I attempted to pan the map examples with Android Talkback on (to scroll you would do a two finger swipe) and found quite a range. For Google Maps embed, I was unable to pan the map at all, and for the other maps there was a varying range of jank levels, where some were fairly smooth and operable (OSM) and some were so janky that it was quite hard to pan to a specific point at all. I'm honestly not sure what I would recommend, but I do feel like current approach across widgets is quite lacking.