Replace `mapml-focus-buttons` with subclass role of composite widget role or proposed `focusgroup` attribute

[Malvoz]

Because map-based popups will be removed there shouldn't be UI components such as mapml-focus-buttons that expect popups (especially one that attempts to solve the general issue with overwhelming keyboard users with tab stops, by allowing users to escape the tab sequence of interactive features).

mapml-focus-buttons is problematic:

• There have to be features with popups for them to be available to users (i.e. not applicable to feature links)
• Users have to open a popup for a feature that they may not be interested in to be able to reach the mapml-focus-buttons

Instead there should be a separate navigation mechanism for users to navigate interactive features: arrow keys. It'll have to be conveyed to AT users that interactive features can be navigated using arrow keys, or else they may think there's only 1 interactive feature on a map because the next tab takes them to the attribution.

There are (soon) 2 ways to achieve that:

One of the non-abstract subclass roles of the composite widget role (e.g. role="grid" & CO)

https://www.w3.org/TR/wai-aria-practices-1.1/#keyboard: > ## Developing a Keyboard Interface > Unlike native HTML form elements, browsers do not provide keyboard support for graphical user interface (GUI) components that are made accessible with ARIA; authors have to provide the keyboard support in their code. https://www.w3.org/TR/wai-aria-practices-1.1/#kbd_generalnav: > ## Fundamental Keyboard Navigation Conventions > ARIA roles, states, and properties model accessibility behaviors and features shared among GUI components of popular desktop GUIs, including Microsoft Windows, macOS, and GNOME. Similarly, ARIA design patterns borrow user expectations and keyboard conventions from those platforms, consistently incorporating common conventions with the aim of facilitating easy learning and efficient operation of keyboard interfaces across the web. > A primary keyboard navigation convention common across all platforms is that the tab and shift+tab keys move focus from one UI component to another while other keys, primarily the arrow keys, move focus inside of components that include multiple focusable elements. > The ARIA specification refers to a discrete UI component that contains multiple focusable elements as a [composite](https://www.w3.org/TR/wai-aria-1.1/#composite) widget. The process of controlling focus movement inside a composite is called managing focus. Following are some ARIA design patterns with example implementations that demonstrate focus management: > > - [Combobox](https://www.w3.org/TR/wai-aria-practices-1.1/#combobox) > - [Grid](https://www.w3.org/TR/wai-aria-practices-1.1/#grid) > - [Listbox](https://www.w3.org/TR/wai-aria-practices-1.1/#Listbox) > - [Menu or menu bar](https://www.w3.org/TR/wai-aria-practices-1.1/#menu) > - [Radiogroup](https://www.w3.org/TR/wai-aria-practices-1.1/#radiobutton) > - [Tabs](https://www.w3.org/TR/wai-aria-practices-1.1/#tabpanel) > - [Toolbar](https://www.w3.org/TR/wai-aria-practices-1.1/#toolbar) > - Tree Grid > - [Tree View](https://www.w3.org/TR/wai-aria-practices-1.1/#TreeView) I belive [`grid`](https://www.w3.org/TR/wai-aria-1.1/#grid) is the most appropriate subclass role of the abstract `composite` role (see [Grid ARIA design pattern](https://www.w3.org/TR/wai-aria-practices-1.1/#grid), [example](https://www.w3.org/TR/wai-aria-practices-1.2/examples/grid/LayoutGrids.html), and corresponding [keyboard interactions](https://www.w3.org/TR/wai-aria-practices-1.1/#keyboard-interaction-for-data-grids)).

Proposed focusgroup HTML attribute

https://open-ui.org/components/focusgroup.explainer: > When writing custom controls, authors need to implement the semantics of various known controls (see [ARIA authoring guide](https://www.w3.org/TR/wai-aria-practices-1.1/)) to enable proper (and expected) keyboard support. > We propose an attribute 'focusgroup' that will facilitate focus navigation (not selection) using arrow keys among a set of focusable elements. The attribute can then be used (without any JavaScript) to easily supply platform-provided focus group navigation into custom-authored controls in a standardized and predictable way for users. Polyfill https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/Focusgroup/focusgroup_polyfill.js.

[Malvoz]

For reference, markers in Google Maps are navigated using arrow keys (though they fail to use appropriate roles for elements per the ARIA design patterns such that users can expect them to be navigated using arrow keys. I may file a bug when I have time to).

[Malvoz]

For reference, markers in Google Maps are navigated using arrow keys

comment related to https://github.com/Maps4HTML/Web-Map-Custom-Element/issues/396:

4. Features out of view should be hidden

In that Google map, the arrow keys only navigate between markers that are currently in view.

[Malvoz]

I'm not sure how we'd use focusgroup in practice, perhaps on leaflet-map-pane or one focusgroup per layer (mapml-layer)?

The latter has the effect, I think, that we could give each layer an accessible name (same as in the layer control) so that it is announced when you tab into that group, e.g.:

Tab 1 (after focusing the map component that is): "Layer A" -> arrow keys move focus between features in Layer A Tab 2: "Layer B" -> arrow keys move focus between features in Layer B

Which would also help conveying hierarchies, something @frastlin brought up in his position statement:

Other attributes, such as hierarchical relationships, or layer relationships, are also important. For example, how can a computer identify an office in a building on a college campus? The office needs to be in the building, and the building needs to be on the campus.

(actually, giving each mapml-layer an accessible name is not dependent on focusgroup: filed https://github.com/Maps4HTML/Web-Map-Custom-Element/issues/579.)

[Malvoz]

Related:

• Leaflet comment describing different keyboard behavior scenarios: https://github.com/Leaflet/Leaflet/issues/7479#issuecomment-974918350 (including focusgroup/ARIA grid)
• Google Maps accessibility issue: Need a better way to instruct screen readers to switch to arrow keys to move through Map Markers (may be worth tracking that issue to see how they deal with it)

[prushforth]

• Google Maps accessibility issue: Need a better way to instruct screen readers to switch to arrow keys to move through Map Markers (may be worth tracking that issue to see how they deal with it)

If there was a specific role for "feature" (map features), screen reader users would become accustomed to using arrow keys for feature focus and tab keys for everything else, perhaps?

[Malvoz]

If there was a specific role for "feature" (map features)

Under Accessibility Considerations -> For Authors for feature we've already defined that:

Implicit ARIA semantics

role=feature

screen reader users would become accustomed to using arrow keys for feature focus and tab keys for everything else, perhaps?

Indeed, perhaps UAs could simply use focusgroup (assuming all goes well with that proposal) for the feature pane.

[prushforth]

Under Accessibility Considerations -> For Authors for feature we've already defined that:

I forgot about that. Is there any way to have a screen reader announce "feature" today when it encounters a feature?

[Malvoz]

Is there any way to have a screen reader announce "feature" today when it encounters a feature?

There's aria-roledescription (features would be role="button|link" aria-roledescription="Feature" aria-label="") but it's not supported everywhere: https://a11ysupport.io/tech/aria/aria-roledescription_attribute#expectations. Features do have aria-label="Feature" by default, so I guess we could change so that featurecaptions are added to it instead of replacing it? e.g. aria-label="Feature: <featurecaption>". We're going off-topic though 😋

[prushforth]

We're going off-topic though 😋

My fault, sorry.