Query handling keyboard access

[prushforth]

A few issues noticed with the the query handler specifically

• reticle is too small and can get lost on a busy / large map
• when the focus is on the zoom in button (+) and the user shift-tabs to put focus on the map, the focus indicator / reticle appears, then instantly disappears when the shift key is released, forcing the user to do shift-tab x 2, then tab, to get focus onto the map
• when focus is on the map and the reticle is visible, Enter OR Spacebar should trigger a query, if possible. At least it should be consistent with the tab-through-features key stroke to activate the popup (in that case it's Enter, in this case it's Spacebar; we could make it easy by enabling either keystroke for both scenarios, if that won't result in other problems).
• when the popup appears, focus is on the div surrounding the iframe. IMHO it should be on the "Next" affordance by default, so that the user can efficiently 'scroll' through all the query results (i.e. or e.g. by repeatedly hitting 'Enter') but is that possible. We haven't yet dealt with figuring out how to get focus into the contents of the iframe.
• When leaving a popup, via Esc or otherwise, the focus should return to the map with the reticle displayed, so that they can continue their investigations.

[Malvoz]

when the popup appears, focus is on the div surrounding the iframe. IMHO it should be on the "Next" affordance by default, so that the user can efficiently 'scroll' through all the query results (i.e. or e.g. by repeatedly hitting 'Enter')

Setting focus to the container is useful, since screen readers announce the content inside an element that recieves focus. And further tabbing would focus interactive elements inside the popup. Changing it to focus the pagination buttons would only announce the button to screen reader users, and would also require keyboard-only users to shift-tab to reach interactive elements inside the popup.

[prushforth]

would also require keyboard-only users to shift-tab to reach interactive elements inside the popup

I agree that is undesirable.

Setting focus to the container is useful, since screen readers announce the content inside an element that receives focus.

If the bypass block was first in tab order, i.e. on the top line of the popup, instead of essentially last and on the bottom line of the popup, specifically if the "Next" affordance was first (i.e. if the "Fast Backwards", "Backwards" affordances were present, but skipped when focusing into the popup, the user could hit tab, tab to focus on the iframe (or better, the first focusable element in the iframe) OR they could hit Enter/Spacebar to go to the next item in scroll order.

Would the screen reader interaction for the above be weird / confusing? I admit it does put an extra screen reader announcement in the sequence.

I'm concerned that the user would need to have a bypass block inside the popup iframe content to get to the popup's 'Next' affordance, if we go from focusing the iframe to tabbing into and then through its contents before getting to the 'Next' affordance, because the journey from iframe to the 'Next' affordance could be many, many tabs long. Although maybe a judicious Esc could 'pop the focus stack' (if there such a thing?).

[Malvoz]

Re:

would also require keyboard-only users to shift-tab to reach interactive elements inside the popup

Note that currently when shift-tabbing from the pagination buttons focus is sent elsewhere, that creates an unnatural tab order. And by sending focus to the pagination buttons in #292 means it's not possible to reach content inside the popup.

---

If the bypass block was first in tab order

(or sending focus to the buttons as is done in #292):

I don't think these options are great because the primary content inside the popup becomes secondary to keyboard-only and screen reader users.

Ultimately I think these controls try to solve issues that are inherited from Leaflet. I believe the "Previous Feature" and "Next feature" buttons are only needed because Leaflet doesn't send focus back to a marker/feature once its corresponding popup has been closed. That is the following item in #247:

• [ ] Pressing the close button in the popup should not send focus to the <body> element, rather the previously focused element (e.g. marker) should be focused (if not available then the map container should be focused). Upstream Leaflet: TBD.

Edit: If I understand correctly that's only true for tab navigable features' popups and not "query popups".

And having both a "Focus Map" and "Focus Controls" would be redundant if the following item in #247 was fixed:

The controls container should come before other author provided content such as popups in the DOM (i.e. .leaflet-control-container should come before .leaflet-map-pane). This reduces confusion by letting users form a consistent mental model of the content, across different maps (perhaps created by different authors, with different content). Relates to SC 1.3.2 Meaningful Sequence, 2.4.3 Focus Order and 3.2.3 Consistent Navigation. Upstream Leaflet: TBD.

because controls would always be the next focusable items after the map has been focused.

I think solving core Leaflet issues is crucial before building new UIs.

[ahmadayubi]

This UI can be built, I don't think it's too big of an ask, it just needs a set of rules to follow, currently the set of rules that need to be followed seem to be changing frequently.

[prushforth]

Sorry about that! OTOH, I think we need to be patient here, as keyboard access is the prime means to provide an accessible map and if there's one thing that sets maps in HTML potentially apart, it will be accessibility.

Also, as I'm not an expert in accessibility, we are really relying on contributors here to keep the conversation going in the right direction.

[ahmadayubi]

No worries I get that, it's a feature that needs to be thoroughly thought out.

[Malvoz]

Looking at the UI again, I do think it makes sense for "query popups" to have this UI, because there are no other means of navigating queries, I think. But I'm not sure the "(Previous/Next) Feature" buttons are needed/helpful in the focusable features' popups (I've edited #291 (comment) to reflect that) because you can already navigate those by tabbing. But that would be a separate issue from this, which I'm not sure is worth raising because while having 2 ways of navigating something may cause more "noise" & tab stops than necessary, it's not breaking anything or necessarily degrading the user experience.

[Malvoz]

Going back to the focus container vs focus buttons:

I'm concerned that the user would need to have a bypass block inside the popup iframe content to get to the popup's 'Next' affordance, if we go from focusing the iframe to tabbing into and then through its contents before getting to the 'Next' affordance, because the journey from iframe to the 'Next' affordance could be many, many tabs long. Although maybe a judicious Esc could 'pop the focus stack' (if there such a thing?).

This is a valid concern, but I'm concerned with users not realizing the main content of the popup if we're to send focus to the buttons. Pagination is pretty common on the web, and when you navigate to next/previous page it's (hopefully) always the body element that recieves focus, but maybe that's a bad analogy.

Pressing Esc when focus is inside popups is almost always (certainly for <dialog>) used to close the popup so doing something else I think would cause a lot of confusion.

[prushforth]

Re-reading this thread, I believe we are left with actions for @ahmadayubi on the following (correct me by comments if necessary):

We can fix this:

• reticle is too small and can get lost on a busy / large map

and this:

• when the focus is on the zoom in button (+) and the user shift-tabs to put focus on the map, the focus indicator / reticle appears, then instantly disappears when the shift key is released, forcing the user to do shift-tab x 2, then tab, to get focus onto the map

If possible, address this:

• when focus is on the map and the reticle is visible, Enter OR Spacebar should trigger a query, if possible. At least it should be consistent with the tab-through-features key stroke to activate the popup (in that case it's Enter, in this case it's Spacebar; we could make it easy by enabling either keystroke for both scenarios, if that won't result in other problems).

No action required here:

• when the popup appears, focus is on the div surrounding the iframe. IMHO it should be on the "Next" affordance by default, so that the user can efficiently 'scroll' through all the query results (i.e. or e.g. by repeatedly hitting 'Enter') but is that possible. We haven't yet dealt with figuring out how to get focus into the contents of the iframe.

This needs to be addressed:

• When leaving a popup, via Esc or otherwise, the focus should return to the map with the reticle displayed, so that they can continue their investigations.

As for:

because controls would always be the next focusable items after the map has been focused.

I think solving core Leaflet issues is crucial before building new UIs.

I didn't realize until re-reading this that the control pane should come before the features in the map, because I considered the features as part of the map, not separate from it. So I'm still not sure about that. I think solving Leaflet issues would be a nice-to-have, but I don't want to get stuck on what Leaflet does as the end game for this component. In fact we might have to replace Leaflet at some point in the future, to attain map rotation, among other features.

[ahmadayubi]

There's one interaction that's a little challenging, when Shift+Tab out of the popup where should the focus go? Should it goto the intial focus of when the popup opened or the map or the feature itself?

[prushforth]

I would be guessing, but I would say the feature itself, i.e. hopefully a screen reader would announce the accessible name @Malvoz

[Malvoz]

Yes screen readers will announce an element's accessible name (assuming there is one) when focused, but also other ARIA properties such as aria-expanded (to be done for features, per @shepazu's suggestion, can open a separate issue for that) and potential role.

I agree and think it makes sense that tabbing out of popups would focus the next/previous feature.

[prushforth]

I agree and think it makes sense that tabbing out of popups would focus the next/previous feature.

I was thinking Shift+Tab would focus the feature that you just dismissed the popup of, if that makes sense. I think it should simply reverse course / retrace steps is what I'm saying.

[Malvoz]

Ah yes, sorry. I meant to say that Shift + Tab out of popup should focus the current/corresponding feature of that popup, not any previous feature. I think we're agreeing. 😋

[Malvoz]

This needs to be addressed:

• When leaving a popup, via Esc or otherwise, the focus should return to the map with the reticle displayed, so that they can continue their investigations.

Is this a suggestion to only apply to query popups? Otherwise can it be the case? Because pressing Esc should not send focus to the map if the popup was opened via a tab navigable feature, which I believe is the case atm.

I.e.:

• if popup was opened via a tab navigable feature, Esc should close the popup and send focus back to the current/corresponding feature of that popup (the element that was initially focused before opening the popup).
• if popup was opened by querying a layer, Esc should close the popup and send focus back to the map (the element that was initially focused before opening the popup).

[ahmadayubi]

These interactions should all now exist in PR #292 . There's also the following interactions left to be defined:

• Shift+Tab out of the query popup
• Tab out of the query popup

I'd think in both of those cases it would just focus the map again?

[prushforth]

Is this a suggestion to only apply to query popups?

I think so.

Because pressing Esc should not send focus to the map if the popup was opened via a tab navigable feature, which I believe is the case atm.

That's not correct, but it does raise the question of where focus should land when dismissing a tabbed-feature popup via Esc or X. I think it should focus the feature that the popup was for.

[Malvoz]

The problem with focusing the map container after closing a popup that the user opened via a tab navigable feature is that they'll potentially have to tab many times to get back to where they were when they opened the popup.

[prushforth]

I think:

Shift-Tab (if taking you out of the popup), Esc or X should focus the feature the popup was for
Tab, if taking you out of the popup, should focus the next feature, if any, otherwise whatever is next in the tab order.

[ahmadayubi]

But what about in the case of query popups and not feature popups?

[prushforth]

In the case of query popup, the tab order coming out of the popup would be:

forward = whatever's after the map, which I believe is the first control in the control layer
backward = the map

I hope I never said it otherwise else where.

[ahmadayubi]

Alright, also should the x button be removed from query popups or should it be added to feature popups? Right now that's an inconsistency between the two.

[prushforth]

I see I may not have been complete here:

When leaving a popup, via Esc or otherwise, the focus should return to the map with the reticle displayed, so that they can continue their investigations.

Tab (forward) would go to the first control, which falls under "otherwise" I suppose

Alright, also should the x button be removed from query popups or should it be added to feature popups? Right now that's an inconsistency between the two.

I think we can keep the X in both, if it behaves like ESC