Early design review: Focusgroup

[benbeaudry]

Braw mornin' TAG!

I'm requesting a TAG review of Focusgroup.

We propose exposing a new web platform primitive—'focusgroup'—to facilitate focus navigation (not selection) using arrow keys among a set of focusable elements. This feature can then be used (without any JavaScript) to easily supply platform-provided focusgroup navigation into custom-authored controls in a standardized and predictable way for users.

• Explainer¹ (minimally containing user needs and example code): https://github.com/openui/open-ui/blob/main/research/src/pages/focusgroup/focusgroup.explainer.mdx
• User research: None yet, but hoping to get some soon.
• Security and Privacy self-review²: https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/Focusgroup/security-and-privacy-review.md
• GitHub repo (if you prefer feedback filed there): https://github.com/openui/open-ui
• Primary contacts (and their relationship to the specification):
  • Travis Leithead (@travisleithead), Microsoft, Explainer co-author
  • David Zearing (@dzearing), Microsoft, Explainer co-author
  • Chris Holt (@chrisdholt), Microsoft, Explainer co-author
  • Benjamin Beaudry (@benbeaudry), Microsoft, Chromium implementor of the feature
  • Daniel Libby, Microsoft, Code reviewer on most (if not all) changes related to this feature
• Organization/project driving the design: Microsoft
• External status/issue trackers for this feature (publicly visible, e.g. Chrome Status): https://chromestatus.com/feature/5637601087193088

Further details:

• I have reviewed the TAG's Web Platform Design Principles
• The group where the incubation/design work on this is being done (or is intended to be done in the future): Open UI
• The group where standardization of this work is intended to be done ("unknown" if not known): Unknown
• Existing major pieces of multi-stakeholder review or discussion of this design: There are some issues filed on Open UI's github repo.
• Major unresolved issues with or opposition to this design: None (or should I say: none that I know of)
• This work is being funded by: Microsoft Edge

You should also know that...

The implementation of the declarative markup part of this feature is mostly completed in Chromium. We still need to discuss further the CSS-part of the proposal before starting to implement it. We feel confident enough about our implementation of the declarative markup part of this feature to start Origin Trials as soon as soon as possible in order to get feedback from the web community and improve it before drafting the specifications.

We'd prefer the TAG provide feedback as:

💬 leave review feedback as a comment in this issue and @-notify @benbeaudry and @travisleithead.

[torgo]

Hi @benbeaudry - you've listed "Unknown" for the trajectory for this work. Can we assume it would be going to HTML (WHATWG) and CSS wg at some point? cc @travisleithead

[benbeaudry]

Yes, this is what I assume as well. @travisleithead, can you confirm?

[AutoSponge]

For https://www.w3.org/WAI/APA/track/actions/2326:

My initial review is very positive. However, the explainer and demo (via polyfill) fail WCAG success criteria when it comes to "nested" focusgroups (via extend). Example 11 demonstrates this in the docs and is very similar to the "vertical menu (with horizontal submenus)" example.

In Example 11, the container-element has tabindex=-1 with no role. In WAI Authoring Practices menu and tree examples, the element "owning" a subgroup is an item, not a separate container with no role.

The problem is evident in the demo when using keyboard navigation. Users must use ArrowDown until reaching a generic element with no accessible name then somehow intuiting that the ArrowRight key to reach the first sub-menu item. In the WAI examples, the direction change begins on a menuitem or treeitem with aria-expanded. Removing the tabindex from the container-element makes the "sub-menu" items unreachable by keyboard. Alternatively, adding role=menuitem to the container and an accessible name (via aria-label or aria-labelledby) seems to fix the issue.

While the use of focusgroup works well in flat structures, its use in nested structures will need better examples that don't lead to focusable elements with no name or role.

[LeaVerou]

@benbeaudry Do you plan to add this to ElementInternals as well? I imagine it would be very useful for many types of web components to have as a default.

We were also wondering what are your thoughts on the point @AutoSponge raised

[chrisdholt]

@travisleithead i don’t think we discussed the above, but a huge +1 to @LeaVerou’s comment above on adding to ElementInternals.

[travisleithead]

@AutoSponge thanks so much for pointing this out.

While the use of focusgroup works well in flat structures, its use in nested structures will need better examples that don't lead to focusable elements with no name or role.

I've done a full pass over the explainer to ensure that all the examples are not only properly structured for accessibility (addressing the example you pointed out), but also added appropriate roles/states on custom element names to help reinforce proper first-class accessibility design. (I'm a little ashamed that I missed this previously because so much of the value of focusgroup is for better keyboard-accessibility-by-default.)

Please take a look at the PR in case there are still problems--I'm still learning to write good accessible examples :)

[LeaVerou]

We took another look today and we generally happy with this feature. We will re-iterate that this should be a part of ElementInternals, but we will go ahead and close this review for now. Feel free to reopen if any future issues arise.
Please engage with the accessibility community to ensure that @AutoSponge’s concerns are addressed and that this feature works well with AT.