RFC: Update the accessibility plugin

[malwoodsantoro]

What problem are we trying to solve?

@ryanhamley and I have been working together to brainstorm how the Mapbox GL Accessibility plugin could be improved to provide a better experience for users with vision impairment or low vision. There are three main issues currently: (1) the location of the map is not described, (2) it’s only possible to tab over existing features randomly because the tab-index of each feature is set to zero, and (3) the user isn’t given a way to meaningfully explore or move around the map.

How does it currently work?

With the plugin, the addControl function is used to add an instance of MapboxAccessibility to the map. This allows the user to define all of the layers and the property in those layers that should be used for voiceover purposes.

The plugin adds an invisible HTML button element on top of each feature with an aria-label property based on what is defined as the accessibleLabelProperty. This allows assistive technology to interpret the symbol as a button with text that is read aloud as the user tabs over the feature.

There are steps at https://github.com/mapbox/mapbox-gl-accessibility#developing to view the demo.

New implementation proposal

When it comes to accessibility, it’s best to follow standardized practices so that users know what to expect and do not encounter an entirely different experience depending on the mapping provider. A few other mapping providers have already taken the same approach (see Esri’s a11y map and Google’s Accessibility mode).

This implementation uses a bounding box that can be moved with the arrow keys. The direction the user is moving is read aloud (i.e. “Moving North”) and then the list of POIs in the area are announced. If a user selects a number corresponding to an announced place, the sidebar opens with all of the details available about the POI. This general idea could work with POIs, but also custom data on Mapbox maps.

Option 1

Add a square div to the top of the map and use the width and height with queryRenderedFeatures. With this option, we could create a div ID parameter for the user to pass when they initialize the plugin so that the functionality can be included in the existing HTML of their page. The direction a user is moving in on the map is announced when an arrow key is pressed which is calculated by retrieving the bearing and assigning the arrow keys accordingly (i.e. “Moving North”, “Moving Southwest”, etc)

See demo https://bl.ocks.org/malwoodsantoro/ad453549bb3cb77a015c7a7addf19cc6

Pros: Performance is great since it is just a fixed div element that sits on top of the map.
Cons: Haven’t run into any yet!

Option 2

Add a canvas source that sits as a square on top of the map. When the user pans the map, a bbox is calculated using the center point and size of the square (see demo).

Pros: Potential for adding more complex rendering on the canvas layer, but not sure when/if that would be useful for this plugin.
Cons: Canvas source visibly updates as map moves.

Options 3

Use a fill layer that is transparent in the center. Each time the map moves, reposition the fill layer to the center of the map and query for the features as described in the approach above.

Pros: Very straightforward and simple to implement.
Cons: Feature visibly updates as the map moves and changes position on zoom.

Other features

• Allow the user to provide a string to be used as an aria-label to announce the location of the map along with some context of what is being displayed (i.e. "A map of ice cream shops in Oakland, California" and to announce how to navigate with the keys (arrow keys for panning and +/- for zooming).
• Allow additional properties to be defined for when the user tabs over a div and presses the corresponding number to tab into the feature for more information.
• Give the developer an interactive: false option that would allow them to use the plugin to only return the features in the bbox. They could then write their own custom code to have more control over the way the features are displayed and read aloud with Voiceover.

Future improvements

• Utilize a circle with the Tilequery API instead of a bounding box so the user could have a better understanding of the geographic area being covered by choosing circle radius from a list of options (in miles or kilometers, for instance).
• Method within the plugin that makes it easier for users to adjust the font size or size of symbols on the map
• Features to accommodate users who experience colorblindness
• Styles using shape and texture instead of color to distinguish between map elements
• Changing colors in style to have a contrast ratio that meets WCAG compliance
  • “WCAG 2.1 requires a contrast ratio of at least 3:1 for graphics and user interface components”

@mapbox/gl-js @tristen @andrewharvey would love to hear your thoughts on this.

[tristen]

@malwoodsantoro this is great!! I have a couple of questions:

• Should this be built into Mapbox GL JS and not require a plugin? It would be awesome if, by default, symbol map data was programmatically determinable with optional configuration when initializing the map object to customize it.

• Is a div container over the map important? Is the map viewport with a focused outline, not enough? I like the ideas that surfaced here for generating a predictable order of features.

cc/ @1ec5

[malwoodsantoro]

@tristen thanks for taking a look!

Should this be built into Mapbox GL JS and not require a plugin? It would be awesome if, by default, symbol map data was programmatically determinable with optional configuration when initializing the map object to customize it.

I think the idea here is that the main GL JS library will continue to improve upon basic accessibility requirements (like your recent updates), while the plugin is tailored to a more specific use case (POIs and other symbol layers).

Is a div container over the map important? Is the map viewport with a focused outline, not enough? I like the ideas that surfaced here for generating a predictable order of features.

Some downfalls I see with the approach of tabbing over features:

• If there are a lot of features on the map, the user has to tab through the list for quite some time to arrive back at their current location or whatever is the "start point". Not a lot of context can be built in this scenario in terms of where a feature exists in relation to the user.
• It’s not possible to understand where a point exists directionally when tabbing. Panning and announcing the direction of the movement allows the user to know where the symbol is in relation to the start point or other features on the map.
• If a user pans beyond the viewport to access more features, there is no sense of the direction they are moving in.

The idea of the square in the center of the map is to provide a more targeted grouping of features rather than including everything in the viewport. We could definitely still sort by proximity to the user within the square itself 👍

[Malvoz]

I highly encourage giving this some more attention. It's a great approach to convey spatial relations to non-visual users.

There is work in progress to enable this in the (Maps for HTML Community Group's) MapML-viewer polyfill:

(You may have to unmute the video)

mapml-viewer-feature-index.mp4

[Malvoz]

Other features

• Allow the user to provide a string to be used as an aria-label to announce the location of the map along with some context of what is being displayed (i.e. "A map of ice cream shops in Oakland, California"

I thought I'd note the related mapbox experiment(?) here: https://www.youtube.com/watch?v=GYWf4Zz4tsE&t=372s