#732: Early design review: Focusgroup

Visit on Github.

Opened Apr 26, 2022

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.

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.

Discussions

Comment by @torgo Apr 27, 2022 (See Github)

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

Comment by @benbeaudry Apr 27, 2022 (See Github)

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

Discussed May 1, 2022 (See Github)

Lea: I think it's a first that focus can be controlled by CSS this way. No precedent. Not sure how it interacts with the HTML attribute.

Peter: something similar about navigation... TV set top box uses case...

Lea: i think it's an amazing idea - but departure from precedent. Says CSS values will override HTML values if they conflict. Like presentation attributes in SVG.

Dan: is this primarily or tangientally an accessibility thing?

Lea: I think it's an accessibility and usability thing

Dan: should we get accessibility people to look at it?

Lea: Can't hurt

Discussed Jun 1, 2022 (See Github)

Dan: noting a11y community feedback - nice to see.

Rossen: assume it's going to evolve through appropriate WGs..

Lea: corresponding attribute to element internals? how can componenets have it by default? Can see many use cases

Rossen: absolutely. Any type of list control. Good question. The example (19) is more or less exactly that.

Dan: this explainer is very developer mindset focussed. Not stating things in terms of the user need. What we're talking about is an accessibility issue, so what accessibility problem are we trying to solve. Is that spelled out?

Rossen: in the goals

Lea: not trying to solve a11y per se, but a developer pain point about accessible interfaces. Helps accessibility indirectly.

Rossen: and connecting the other end with ATs so they can build on top of this. No accessibility solution that don't includde 3 parties - developers, engines, and the screen reader / etc technologies. Unless all of these things work together you don't have an accessible solution. Which one of these are you asking about?

Dan: trying to parse the user need from the explainer. Could be better spelled out.

Lea: I'd like to see a response to the point in this comment - seems like a reasonable question.

Dan: can you amplify the question?

Lea: yeah

Comment by @AutoSponge Jun 19, 2022 (See Github)

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 <kbd>ArrowDown</kbd> until reaching a generic element with no accessible name then somehow intuiting that the <kbd>ArrowRight</kbd> 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.

Comment by @LeaVerou Jun 20, 2022 (See Github)

@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

Comment by @chrisdholt Jun 20, 2022 (See Github)

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

Comment by @travisleithead Jun 22, 2022 (See Github)

@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 :)

Discussed Aug 1, 2022 (See Github)

Dan: we've had feedback - added material around a11y in explainer. This is in response to Lea's feedback and could be addressed. Lea should review.

Dan: their PR 550

Discussed Aug 1, 2022 (See Github)

Lea: any movement?

Dan: not since June. A PR merged in mid June which is about a11y.

Lea: I don't have the a11y knowledge to evaluate how serious this concern is.

Dan: did Travis's comment address your issue? Not really

Lea: don't think it should be a blocker. Just a matter of doing it. the other thing is this person who raised this concern and I'm not sure how serious it is.

Dan: we could bring in external help?

Rossen: the overall issue that Paul raised was with some of the.. one of the examples which was addressed by the api itself and the ability to navigate through focus groups. The way I read this comment is I believe he was misled by the example in believing that the tab index in combination with focusgroup is going to be an issue. Which explicitly I think somewhere in the explainer.. section 6 focusgroup concept.. talking about overall interaction between tab index and how that extends to handling of focusgroup and focus. So generally speaking focus mangaement and focus itself is a fairly loaded issue on its own. I can help if I spend some time. Distanced myself since I was involved in the initial design, a couple of years ago. I don't see the concern from Paul as being something that should block progress.

Dan: close satisfied?

Lea: [comments] - can reiterate the thing about element internals? Anything about Paul's point?

Dan: could say please engage with the accessibility community to ensure they look at this. [APA]

Rossen: pretty sure they already have. Done in part with the help of the community. Not in a vacuum. But fine to remind them.

Agree to close

Discussed Aug 1, 2022 (See Github)

punt to plenary

Comment by @LeaVerou Aug 31, 2022 (See Github)

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.