Adding an accessibility menu when tabbing to allow user to select what item should be focused

[ahmadayubi]

Would adding a menu that is only accessible when tabbing be good for accessibility, similar to how Google search has a menu of links, first one being able to control what element is in focus next.

In the case of mapml viewer it would be a menu of what should be focused next i.e. features, zoom controls, layer controls, etc.

2021-01-27.16-00-05.mp4

@Malvoz is a menu like this standard and warranted?

[prushforth]

@Malvoz, @shepazu Is this accessibility menu part of a Web standard for accessibility?

[Malvoz]

That's a convention sometimes referred to as "skip links": https://webaim.org/techniques/skipnav/.
Here's an example: https://genericcomponents.netlify.app/generic-skiplink/demo/index.html.

It works by using a CSS hack to visually hide the links and unhide them as they recieve focus. There is no standard way to hide something that's intended to be focusable (related discussions, FWIW: w3c/csswg-drafts#560, w3c/css-a11y#13).

It's indeed helpful, it relates to SC 2.4.1 Bypass Blocks. I suppose I can see a standard implementation of it (both as a CSS property and as a default facility in maps) but I think that's also based on assumptions of how users currently interact with maps (and what is keyboard accessible, under which circumstances).

[Malvoz]

I accidentally stumbled upon a demo found in https://github.com/Canadian-Geospatial-Platform/GeoView which uses a menu like that. I don't believe a native implementation should need such a menu but thought I'd report the find nevertheless.

[Malvoz]

I believe navigation can be made intuitive and accessible through proper DOM order and keyboard shortcuts, along with the navigation controls in popups. Hopefully even more so through #396 and #397.

A menu such as described here should not be necessary. I'm closing this, feel free to continue discussing or re-open.