Adding tabbing navigation and accessibility to map

[ahmadayubi]

2021-01-29.09-28-12_Trim.mp4

Allow features to be tab navigable and add crosshair to map when query layer exists + map is tab focused

Closes #268 also closes #260

Edit:
Now adds navigation bypass

2021-02-05.10-39-17.mp4

Closes #280

[Malvoz]

The features are indistinguishable to someone relying on a screen reader as they don't have an accessible name. <path tabindex="0"> is announced as graphic in Chrome (blank in Firefox):

Keyboard.Interaction.Test.-.Google.Chrome.2021-02-01.01-37-.mp4

[Malvoz]

When using the NVDA screen reader it's not possible to open popups by pressing Enter or Space when a feature has focus. This works on other elements such as controls, supposedly because they're standard interactive elements.

[prushforth]

The features are indistinguishable to someone relying on a screen reader as they don't have an accessible name.

I see that the <path> element supports a child <title> element that provides an accessible name. If we can come up with a convention for providing a similar accessible name for <feature>, we could generate the <path><title> from it.

When using the NVDA screen reader it's not possible to open popups by pressing Enter or Space when a feature has focus.

That's a problem. Open to suggestions to achieve this. Maybe we should open the popup when the feature receives focus, and dismiss it on blur?

[ahmadayubi]

Maybe we should open the popup when the feature receives focus, and dismiss it on blur?

I think opening a pop up on focus alone might be an annoying interaction to have with a webpage. Adding a title element seems like a good solution based off: https://www.w3.org/TR/SVG11/struct.html#DescriptionAndTitleElements .

[prushforth]

I think opening a pop up on focus alone might be an annoying interaction to have with a webpage.

I'm not saying you're wrong, just want to think about this a bit here.

When a user clicks or touches a feature when the map isn't in "focus mode", the feature either pops up a balloon or if there's a query available it pops up a balloon after receiving the response. Presumably (I am presuming) tab-to-focus a feature is the equivalent operation to touching it for a sighted person, so the user wants to hear the properties if they're using a screen reader.

Given the extremely generic properties model that <feature> has, I wonder if we should add a <title> element child of <properties> as a special case for accessible names purposes similar to svg. In the polyfill we can map that to <title> or what have you. I'll open an issue on this latter discussion in the MapML and UCR document repos.

[prushforth]

I think in the short term, we could generate an accessible name on the element that has the value <path><title>feature</title></path>. I think if a feature isn't provided an accessible name in the future (even if we add <title>), we'll still have to generate something that screen readers can announce (they might not need a fake <title> if they ever come to support <feature>).

[Malvoz]

I think opening a pop up on focus alone might be an annoying interaction to have with a webpage.

I'm not saying you're wrong, just want to think about this a bit here.

When a user clicks or touches a feature when the map isn't in "focus mode", the feature either pops up a balloon or if there's a query available it pops up a balloon after receiving the response. Presumably (I am presuming) tab-to-focus a feature is the equivalent operation to touching it for a sighted person, so the user wants to hear the properties if they're using a screen reader.

Tab-to-focus is more of a discovery phase (perhaps tedious, depending on the amount of features), where e.g. <title> would provide the accessible name for discernibility (discernibility is also an issue present for regular focusable markers!). Touching is equivalent to pressing Enter or Space once an element has focus. I agree that popups shouldn't open on focus.

"focus mode" is a term to describe one of few modes in screen readers but I take it you're referring to when the reticle is visible? This mode currently has some usability issues:

1. The user doesn't necessarily know they can press Space to get details for features. aria-keyshortcuts may be useful here, but visual users would need this info on screen. Of course, if this was a standard behavior people would know this by heart.
2. Features that have other features stacked on top of them cannot be interacted with, I believe.
3. Particularly screen reader users:
   • don't know which feature the reticle is on at any given moment (which feature is available to them). Although if features are in the tab order then they can reach them by sequentially navigating instead.
   • don't know that they're actively panning (and in which direction) when pressing the arrow keys as there is no such feedback (but I suppose this is a stand-alone issue, which is also true in regards to zooming).

(Also popups aren't announced when opened. This is an issue with Leaflet popups in general, we're tracking the upstream issue in #247.)

Esri's a11y-map (yes I'm referring to them again! 😋) doesn't have these issues because each feature within the "scope" is:

1. Announced to the user via ARIA live regions when panned to.
2. Assigned a keyboard shortcut that can be pressed, to expand details.
   
   
   
   pressing 1 reveals:
   
   

I think the a11y-map's interaction model is intuitive, it doesn't need to include features in the tab order (unlike regular documents).

[ahmadayubi]

a11y's querying is similar to Google's, and it works well when you have a discrete number of features. In mapml from what I can tell there can be a continuous number of queryable points on the map. There's querying a layer and querying a feature. Querying a layer is continuous but "querying" features is discrete. If you had to use the square model of a11y or google maps you would only show that conditionally as you still have the issue of continuous querying.

I guess you could introduce a new crosshair + square hybrid? Where numbers query a feature but space queries the center?

[Malvoz]

I'm getting a strange bug where the popup is misplaced when opening it by pressing Enter, only when using a screen reader (NVDA in this case):

Keyboard.Interaction.Test.-.Google.Chrome.2021-02-03.21-01-.mp4

[Malvoz]

Why are close buttons not useful in feature's popups?

[prushforth]

I think @shepazu mentioned they might be problematic, or it might have been me misinterpreting something...

[ahmadayubi]

It was suggested that it be removed, should it be added back?

[shepazu]

I think having a close button is fine, with the following caveats:

• the popup should not be a modal (that is, it shouldn't be a focus trap)
• if possible, we shouldn't force screen reader users to "close" each feature popup to move on to another feature

This seems like somewhat competing experiences between voice-control and screen-reader users, in exposing the right amount of detail with the fewest possible number of forced interactions. My preference would be to have the popup not exposed to screen readers on focus, but only read the accessible name (the popup "title"), with notification of additional information (e.g. aria-expanded) to access the other popup details only on demand (at which point they might encounter the close button, but that's fine, because they chose to expand it). For voice-control users, I think having the popup on focus should be good, with scrolling for long details, and a close button.

Does this seem right to you, @Malvoz?

[Malvoz]

I think having a close button is fine, with the following caveats:

• the popup should not be a modal (that is, it shouldn't be a focus trap)

The popups are non-modal, so focus traps are (mostly*) not an issue.

*when the popup for the last feature in the sequence is opened tabbing is currently trapped to some extent (shift + tab can be used to move back to the previous feature):

Keyboard.Interaction.Test.-.Google.Chrome.2021-02-08.11-06-.mp4

if possible, we shouldn't force screen reader users to "close" each feature popup to move on to another feature

Because focus (generally) isn't trapped inside popups users don't have to explicitly close popups before moving on to other features/focusable elements.

This seems like somewhat competing experiences between voice-control and screen-reader users, in exposing the right amount of detail with the fewest possible number of forced interactions.

I'm not super familiar with voice-control so I'm not sure about how there are competing experiences here. I do know that some people use voice-control to move their cursor around to interact with elements, in that case I think a close button could be appreciated if they just wanted to close a popup without opening a new one.

My preference would be to have the popup not exposed to screen readers on focus, but only read the accessible name (the popup "title"), with notification of additional information (e.g. aria-expanded) to access the other popup details only on demand (at which point they might encounter the close button, but that's fine, because they chose to expand it).

Yes I think we agreed that popups should not be opened (and thus exposed to ATs) when a feature recieves focus, and that each feature itself should be labelled for discernibility. (discussion from #270 (comment))

I agree that features that are interactive and have popups should expose the state of the popup using aria-expanded.

[prushforth]

I think the reticle / graticule could be about 2x as big and bold, personally. I find it easy to not notice. WDYT?

[ahmadayubi]

I'm getting a strange bug where the popup is misplaced when opening it by pressing Enter, only when using NVDA:

@Malvoz when I use it I don't even get a popup? I put a breaker on leaflet code responsible for creating the popup and it seems with NVDA running that code is never reached, Certain keyboard events might be getting hijacked?

I found this:

Source http://melmo.github.io/accessibility/code/dist/leaflet.html

[ahmadayubi]

I think the reticle / graticule could be about 2x as big and bold, personally. I find it easy to not notice. WDYT?

For reference this is what 2x would look like, that's not considering bolding either. It goes from being a map with a UI to being a UI with a map, if that makes sense, but you're right in that it might make seeing it easier. Pros and cons.

Currently its 36x36px, maybe making it 44x44px is appropriate so it's the same size as the buttons?