Improve the default navigation flow for keyboard and screen reader users

[Malvoz]

Motivation

The DOM order of elements affects the order in which screen readers announce content, and also the focus order.

I believe that the map controls should be available/presented to the user before other author provided content such as markers and popups.

This would reduce confusion and allow non-visual users to form a consistent mental model of the content. It also creates a more consistent and logical focus order even across different maps (perhaps by different authors) with varying content.

Relates to WCAG 2.1 Success Criterion 2.4.3 Focus Order and 3.2.3 Consistent Navigation.

Proposed solution

Change leaflet-control-container to come before leaflet-map-pane in the DOM order.

Arrow key navigation for focusable elements in leaflet-map-pane.

Additional context

@stevevance raised a similar concern in #3210 (quoting the relevant parts):

I was testing my website with a person who is completely blind and uses the VoiceOver (VO) function on an iPad. I was observing her as she browsed the entire webpage (through a tapping function in VO that mimics tabbing between elements*) and came across the Leaflet map.

Expectations

The next tab should land on the zoom controls, layer controls, and any other controls, so the user can understand what functions are available to control the map.

The next tab should land on any marker that has a popup

[Malvoz]

I believe that the map controls should be available/presented to the user before other author provided content such as markers and popups.

While I think this would be an improvement (especially when there are a lot of markers), the problem with this approach is that it causes disruptive tab stops between panning and interacting with the markers.

Below are descriptions of 3 different methods that I think should be considered. For each method, the scenario is a map with 100 markers.

🔗 A. Current situation

1. Tab to map
2. Tab through 100 markers
3. Tab to controls

In this situation, it would take more than 100 tab presses to reach the controls, to go into fullscreen for example. It's also difficult for users relying on screen readers to detect the available controls.

🔗 B. Changing DOM order (#7796)

If the DOM order of the map pane and controls is changed:

1. Tab to map
2. Tab through a few controls
3. Tab to markers

Now it's easy for keyboard users to use the controls but will have to Tab between map -> controls -> markers and Shift + Tab between markers -> controls -> map when they only want to pan and interact with markers. I.e. they're forced to tab past the controls each time.

🔗 C. Arrow key navigation for focusable elements in leaflet-map-pane

The optimal solution (that I can think of) would have to be something more like how e.g. Google's marker accessibility works - markers are navigable using arrow keys:

1. Tab to map
2. Tab to markers (now use arrow keys if you want to navigate between markers)
3. Tab to controls
   
   There are potentially 2 ways to achieve this:

   1. Implement something like the ARIA Grid pattern
      (The more complex option)

   2. Set the focusgroup attribute on leaflet-map-pane, done!
      (Well, that's in theory, focusgroup is a new proposal by Microsoft, which would need to be polyfilled)

      Edit: new home for the focusgroup proposal: https://open-ui.org/components/focusgroup.explainer

[Falke-Design]

I think solution "C" would be good. But I don't think that the other maintainers allows the polyfill for focusgroup. Btw. with focusgroup it looks like focusegroup='extend' would be needed too.

So we need to use the ARIA Grid pattern.

[Malvoz]

I think solution "C" would be good.

Just noting that arrow key navigation for markers would resolve a concern described in #3472 (comment):

as mourner said in #1355 :
"an interesting accessibility problem... If the number of markers is too high, people will have big trouble tabbing through all the markers to get to other elements of a page"