-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Replace mapml-focus-buttons
with subclass role of composite widget role or proposed focusgroup
attribute
#535
Comments
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). |
comment related to #396:
In that Google map, the arrow keys only navigate between markers that are currently in view. |
I'm not sure how we'd use 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): Which would also help conveying hierarchies, something @frastlin brought up in his position statement:
(actually, giving each |
Related:
|
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: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:
https://www.w3.org/TR/wai-aria-practices-1.1/#kbd_generalnav:
I belive
grid
is the most appropriate subclass role of the abstractcomposite
role (see Grid ARIA design pattern, example, and corresponding keyboard interactions).Proposed
focusgroup
HTML attributehttps://open-ui.org/components/focusgroup.explainer:
Polyfill https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/Focusgroup/focusgroup_polyfill.js.
The text was updated successfully, but these errors were encountered: