role="application"

[Malvoz]

I wonder if role="application" should replace role="region" on the leaflet-container. See w3c/csswg-drafts#5275 (comment) for background information.

Screen readers have different modes of operation, I believe the default mode is usually "browse mode" (this is true for NVDA), in browse mode you can use the arrow keys to read text in a certain direction, for example. Because browse mode intercepts keyboard commands, it is currently not possible to:

• Pan the map display
• Open the context menu

There's also an issue with misplaced popups.

With the implications on keyboard interactions from role="application" we wouldn't have these issues, because:

Keyboard interaction is completely under the web author's control and can be anything associated with the particular widget being implemented.

But that can cause confusion for the user, as they may not be able to operate their screen reader as they typically do with keyboard commands (see NVDA default keyboard shortcuts for reference). Of course, a user can switch between modes, but how would they know to do so, to enable panning etc.? Does the typical screen reader user even know how to manually switch modes? I obviously don't have a good enough understanding of how every day screen reader users use their tool. @nchan0154 do you happen to have any insight to this?

Esri's a11y-map uses role="application" (and their interaction model for keyboard users is superb by the way, panning is the primary interaction method as opposed to sequentially navigating through focusable features).

[nchan0154]

I believe generally those who use screen readers due to disability consider themselves highly proficient (68% would classify themselves as advanced, though obviously those who would respond to a survey may be a self selecting group) and would be capable of manually switching modes!

Whether or not I'd recommend setting role="application" initially is a trickier question. Everything I've learned really impresses on you to use it with caution, though a map may be one of those rare use cases where it works well, the fact it overrides all keyboard interactions really can let us potentially imagine what could be possible (or inadvertently break everything!).

Given the lack of precedent in our examples, I'd really want to test a whole bunch before making a decision, or at least speak to Esri's a11y-map team to understand their decision (I think I saw one of the team members in the a11y slack, are you a part of it? I can invite you if that would be helpful!) I actually can pan the map examples by switching into forms/application mode manually so at least panning is possible with a screen reader, but since there is a lack of audio feedback once the map is panned, I'm not sure how useful it is. I suppose it really depends on the goals of this repo, if we are trying to really make this the most accessible map we can, we'd need to think about htis more holistically and we'd want to consult a lot more folks before making a decision.

[Malvoz]

a map may be one of those rare use cases where it works well, the fact it overrides all keyboard interactions really can let us potentially imagine what could be possible (or inadvertently break everything!)

If we were to do this, we could perhaps set role="document" for things like author provided HTML (e.g. popup content) so that they don't inherit the application role's behavior, such that keyboard interactions for any standard element within the popup work as usual without requiring additional handling. Hopefully switching modes for the user isn't too confusing in that case.

I'd really want to test a whole bunch before making a decision, or at least speak to Esri's a11y-map team to understand their decision (I think I saw one of the team members in the a11y slack, are you a part of it? I can invite you if that would be helpful!)

Sure that'd be great! 👍🏼

I actually can pan the map examples by switching into forms/application mode manually so at least panning is possible with a screen reader, but since there is a lack of audio feedback once the map is panned, I'm not sure how useful it is.

Requiring users to switch modes for something as essential (I assume, in a standard map viewer) as panning the map display seems a bit like an obstacle, but I concluded that since screen readers already occupy the arrow keys to read text in a desired direction, they'd probably assert a default (but configurable) combination of modifier keys + arrow keys for "standard panning". But as I write this I'm thinking maybe it even makes total sense for screen readers to allow for pressing arrow keys to pan in a desired direction when the map viewer has focus, assuming appropriate audio feedback is given. It's basically "read text in a direction" right? (well, features, POIs.) 😋

I suppose it really depends on the goals of this repo, if we are trying to really make this the most accessible map we can, we'd need to think about htis more holistically and we'd want to consult a lot more folks before making a decision.

I agree!

[Malvoz]

Re my own comment:

Hopefully switching modes for the user isn't too confusing in that case.

There's distinct audio feedback in the form of a beep to indicate when the user enters/exits parts of documents with role="application", which I believe screen reader users may be familiar with.

[Malvoz]

I'd feel pretty comfortable going forward with this if we had Meaningful Pan & Zoom (and Feature navigation) in place. Because if we're "hijacking" keyboard controls, we must ensure that when the user is navigating the map - e.g. using the arrow keys to pan, and +/- to zoom - that it makes sense and it is intuitive.

On top of that, a Feature Index would allow the user to explore POIs/markers without continuously having to tab to reach POIs, and then shift + tab (potentially through many markers) to get back to the map container whenever they want to pan.

Of course, this all would need a lot of testing, and feedback from avid screen reader users.