Meaningful Pan & Zoom (and Feature navigation)

[Malvoz]

A developer reached out to me some weeks ago, and wrote I found you through your contributions to Leaflet and Maps4HTML, I'm trying to decide on an open-source map library and one of my priorities is accessibility, Would you be willing to provide some advice regarding the state of accessibility with these mapping libraries?.

Not only do all of the libraries fail to implement a basic UI in an accessible manner (i.e. #247), but panning and zooming is for the most part meaningless to non-visual users.

Can pan and zoom (and map navigation as a whole) be made useful and meaningful, to everyone?

The problems

1. Panning & zooming is not meaningful to users of assistive technology

   • There is no feedback provided to the user during/after pan and zoom, so these actions have no meaning to a non-visual user.
   • Panning and zooming has (mostly) no effect on the visibility/focusability of elements, which leads to the next problem:

2. Navigating only features of interest

   • It's not possible to only navigate features currently in view (whether "currently in view" is limited to a square in the center of the map or the visible content of the map viewer itself). Currently, if only 1 out of 100 focusable elements are in view there are still 100 elements in the tab order.

Potential solution(s)

(These solution parts are highly inspired by the Google Maps site's "Accessibility Mode" and Esri's a11y-map, and rely on role=application such that screen reader users can pan using arrow keys as well).

1. The direction in which the user is panning should be announced

   • Example: pressing → should announce Moving East (although cardinal directions are not relevant in drawings or schematics without geographic coordinates).
   • Why? This would allow non-visual users to learn in which direction a feature is located in relation to others.
   • How? A (potentially sr-only) ARIA Live Region element (e.g. role="status" with aria-atomic="true"):
     
     

     <output role="status" aria-live="polite" aria-atomic="true" class="mapml-screen-reader">
       Moving <span>East</span>.
     </output>
     <!-- 
     <output> is implicitly role="status" in supporting browsers.
     It's recommended to explicitly set the role to bridge the gaps:
     https://www.scottohara.me/blog/2019/07/10/the-output-element.html#bridging-gaps
     -->

2. The zoom level should be announced (Announce zoom #664)

   • Example: pressing + (or Enter/Space when the Zoom In control has focus) should announce e.g. Zoom level 10.
   • Why? This would allow non-visual users to learn how much to zoom in/out to reach a certain feature (but also the initial zoom level).
   • How? A (potentially sr-only) ARIA Live Region element:
     
     

     <output role="status" aria-live="polite" aria-atomic="true" class="mapml-screen-reader">
       Zoom level: <span>10</span>.
     </output>

3. Min/max zoom & pan should be announced when reached

   • Example: pressing - (or Enter/Space when the Zoom Out control has focus) and reaching the minimum zoom level should announce e.g. Minimum zoom level reached: zoom out disabled.
   • Why? This would allow non-visual users to learn that they've reached the min/max zoom level and/or bounds of the map.
   • How? A (potentially sr-only) Live Region element:
     
     

     <output role="status" aria-live="polite" aria-atomic="true" class="mapml-screen-reader">
       <span>Minimum</span> zoom level reached: zoom <span>out</span> disabled.
     </output>
     
     <output role="status" aria-live="polite" aria-atomic="true" class="mapml-screen-reader">
       Map bound to <span>East</span> has been reached: panning <span>East</span> disabled.
     </output>

4. Features out of view should be hidden
   (proposed capability: Capability: Hide or show content outside the map display HTML-Map-Element-UseCases-Requirements#239)

   • Why? They aren't relevant to the user.
   • How? Set elements out of view as inert.

5. Features in view should be announced

   • Example: There are 2 features on a map, labelled "Feature A" (in view) and "Feature B" (out of view), "Feature A" should be announced on initial load of the map, after panning Feature B into view "Feature B" should be announced.
   • Why? This would allow non-visual users to know which features are currently available.
   • How? Screen readers announce content that is visible by default, on page load & when the user focuses the map viewer (in the example, "Feature A" is currently announced correctly). But screen readers don't announce content that has its visibility (e.g. inert attribute) toggled. To have features announced as they become visible on pan/zoom I believe either of the following would be required:
     • a) All features be part of a Live Region element(s) and trigger a change as needed for screen readers to react to Live Regions, this would probably introduce other issues. Or
     • b) Each feature name (derived from <featurecaption> (<g aria-label="">)) added to a Feature Index (Feature Index #397) Live Region element (it could be sr-only by default, and a control could be provided to toggle between "screen reader only" and "visible to all").

---

Related comments/issues:

• Adding tabbing navigation and accessibility to map #270 (comment) + Adding tabbing navigation and accessibility to map #270 (comment)
• Assign tabindex=n in ascending order of distance of feature from map centre #385
• Feature tab order experiments#2

Related experiments:

• https://maps4html.org/experiments/screenreader/feature-index/
• https://maps4html.org/experiments/screenreader/announce-pan-zoom/

[prushforth]

We're trying to make features, and maps, accessible, and to make features part of the way that screen reader users will be able to navigate a map, including being a way to achieve what zoom and pan do for sighted users, without having to actually use pan and zoom directly. I am a pan and zoom sceptic when it comes to the accessibility maps you've mentioned, or really any map for that matter. Although I understand that announcing direction of travel might be of use, I think that users would not care about that if they didn't have to; if they could leverage the "power" of linking to get them to the thing they need to get to. We have not yet hit upon an optimal solution but we're making progress.

I also think that sorting the features in a map by "relevance" (mostly: ascending order of distance from centre of map) could help with having to go through too many features. Features are necessary, but too much feature spoils the map. So Ctrl-F could also help, if we ever get to it (getting links implemented is occupying all our efforts atm).

[prushforth]

btw this is not a complete answer, just acknowledgement of the issues. Hopefully I'll have time to respond to bits appropriately

[Malvoz]

Thank you for your initial response Peter!

We're trying to make features, and maps, accessible, and to make features part of the way that screen reader users will be able to navigate a map, including being a way to achieve what zoom and pan do for sighted users, without having to actually use pan and zoom directly.

I want to clarify that this particular proposed solution and conventional tabbing are not necessarily mutually exclusive.

I am a pan and zoom sceptic when it comes to the accessibility maps you've mentioned, or really any map for that matter.

Conversely, I'm skeptic to tab-only navigation in maps. Tabbing (as the only way) to explore a map:

• Provides a blind user no insight into features' spatial relations (other than that they belong to the same map)
• Forces navigation of features to a fixed sequence dictated by the mapml author(s) (whereas pan & zoom is "free" exploration). so tabbing pretty much ensures the user will - for better or worse - encounter each feature on the map.
• Requires the user to press tab each time they want to navigate to/discover a new feature (whereas with panning the user can cover multiple features more quickly in the same amount of key strokes).
• Requires keyboard-only users to press shift + tab for as many times as needed to get back to the map container (alternatively requires the user to press Enter on any feature (which might not be of interest) and navigate to the mapml-focus-buttons to press the Focus Map button) to be able to pan or zoom.

Although I understand that announcing direction of travel might be of use, I think that users would not care about that if they didn't have to; if they could leverage the "power" of linking to get them to the thing they need to get to.

Direction of travel isn't going to be of interest to all screen reader users in all scenarios/at all times (ATs are likely to have map-viewer specific settings so affordances of this type may be opt-in/out), but I think it's a big assumption to say that it's not useful because we have links. Links with target destinations within maps are certainly useful in their own right, though sometimes it's the journey that counts, not (only) the destination.

I also think that sorting the features in a map by "relevance" (mostly: ascending order of distance from centre of map) could help with having to go through too many features.

The answer here too is that they (this proposed solution and #385) may not be mutually exclusive.

Ctrl-F could also help

I agree that supporting ctrl + F is important. I've mentioned the use of the inert attribute (polyfill), which has this note in the README:

When a node is inert, then the user agent [...] may ignore the node for the purposes of text search user interfaces (commonly known as "find in page")

The above isn't true for the polyfill though. It'd be neat to hinge on their work for making sure out-of-view content is truly hidden from ATs (but not visually hidden) as it applies aria-hidden="true" and tabindex="-1" to all interactive (and interactive descendants of) elements set to inert. Supposedly it'd be safer to rename the attribute (e.g. data-mapml="inert") and remove any potential feature detection to avoid UAs from hiding the content from search, such as to only utilize the "hide from ATs and tab order" features of the polyfill. This (how to hide things from ATs and tab order) is a detail not really relevant to this discussion though, but just clarifying that my intention was not to suggest hiding things from "find in page".

[prushforth]

Another thought: the tile structure could be used to advantage to allow blind users to "explore" a geographic space, because it's regular enough to develop a reliable mental map of, and known to the UA. The UA could announce the zoom/row/column and allow controlled pan/zoom so the user would never get lost.

[Malvoz]

I've updated the initial comment to add a new part: 3. Min/max zoom & pan should be announced when reached. Partially inspired by Tabletop tangible maps and diagrams for visually impaired users (PDF) (Chapter 5, 2.3.2 KEYBOARD INTERFACE, page 202):

If the user cannot move the viewport (because one of the edges of the map has been reached) or cannot zoom in or out, feedback is provided accordingly (e.g. “Impossible to go to the right”, “Impossible to zoom in”).

The solution parts:

1. The direction in which the user is panning should be announced

2. The zoom level should be announced

3. Min/max zoom & pan should be announced when reached

are in some ways analogous to aria-valuemin, aria-valuemax, aria-valuenow / aria-valuetext, and/or aria-disabled (these ARIA properties and states are however restricted to certain ARIA roles and as such cannot be used for the purpose of these solution parts, even if it would've made sense to use them).

In other words, the polyfill would expose information to the user that perhaps should be exposed through accessibility APIs in a standard element.

[Malvoz]

Just noting that, to my understanding, this proposed solution (the solution parts together) creates an egocentric viewpoint (which seems to be favored by Brandon Biggs in https://discourse.wicg.io/t/digital-nonvisual-maps/4838) as opposed to an allocentric viewpoint (current state of web maps, through sequential navigation).

[Malvoz]

I reached out to Brandon per e-mail and he noted that the a11y-map has significant latency in announcing the view, this is partly due to the use of aria-live="polite", but their implementation also has a bug that causes the previously announced direction (e.g. Moving west) to be announced when zooming in and out (and even after closing dialogs IIRC), which may contribute to perceived latency.

aria-live="assertive" may result in a better user experience, but the spec states:

User agents or assistive technologies MAY choose to clear queued changes when an assertive change occurs. (e.g., changes in an assertive region may remove all currently queued changes)

which perhaps means that the proposed alerts would have to reside in a single <output> element instead, where the individual parts (zoom level, cardinal direction, min/max zoom & pan reached, etc.) are removed from/added to the DOM on user input for proper announcement.

[ben-lu-uw]

Hi @Malvoz we are trying to set the zoom and location of the map on moveend in the aria label of the div that has focus however when we set the aria label back to interactive map at the end, the words "interactive map" is being read again. Is this an issue that we will have to resolve and if so, do you have any ideas. Thanks!
https://github.com/ben-lu-uw/Web-Map-Custom-Element/tree/announce_zoom_and_move

[Malvoz]

Is there a particular reason why the suggested output element is not used?

[ben-lu-uw]

Wouldn't focus have to shift to the output element and then shifting focus back to the map would lead to the same issue?

Edit: Never mind I see that it does not need focus. Ill give it a go thanks!

[Malvoz]

@ben-lu-uw one caveat is that the output element (or any ARIA live regions) can't be dynamically added to/removed from the DOM, but rather its contents should. Here's another great article: https://bitsofco.de/using-aria-live/#considerationswhenusingarialive