Intent to Prototype: Focusgroup

[Benjamin Beaudry]

Contact emails 

bebe...@microsoft.com 
 
Explainer 

https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/Focusgroup/explainer.md 
 
Specification 

 

Summary 

The Focusgroup feature will facilitate keyboard focus navigation using the keyboard arrow keys among a set of focusable elements. 

Blink component 

Blink>DOM 

Motivation 

By providing this primitive built-in the browser, authors will be able to provide this functionality without relying on custom solutions that often lead to a lack of consistency, accessibility and interoperability. 

Initial public proposal 

https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/Focusgroup/explainer.md 

TAG review 

(note might need to kick this off as an "early review" if not done already…) 

TAG review status 

Pending 

Risks 
 
 

Interoperability and Compatibility 
 
Gecko: No signal 
 
WebKit: No signal 
 
Web developers: No signals 
 
Other signals: 

Debuggability 
 

Is this feature fully tested by web-platform-tests? 

No 
 

Flag name 
 Doesn't exist yet, but will be added to runtime_enabled_features.json5 as "Focusgroup".

Requires code in //chrome? 

False 

Tracking bug 

https://bugs.chromium.org/p/chromium/issues/detail?id=1286127 

Estimated milestones 

No milestones specified 

Link to entry on the Chrome Platform Status 

https://chromestatus.com/feature/5637601087193088 

This intent message was generated by Chrome Platform Status. 

Cheers,

Ben

[Jacques Newman]

It's been a while since the last round of prototyping and origin trial, but I working to move this feature forwards again and will be updating the implementation to match the scoped explainer I proposed in OpenUI.

Since the chromium implementation was developed, a lot of changes have gone into the original, un-scoped explainer as folks have worked towards solving the issues of the original implementation. I have taken much of the new approach but worked to scope it down, addressing accessibility concerns in the process. The new, scoped explainer I have proposed details the differences between it and the original, so I won't spend time explaining these differences here, but will instead focus on what will need to change to get our implementation to align with the new proposal.

Major Differences from the prior implementation are listed below, please see the Scoped Focusgroup (Explainer) for details and examples:

• Focusgroup is Scoped to Recognized Patterns: Focusgroup is now limited to a concise set of composite widget patterns that can be mapped to corresponding aria roles. This prevents ensures that usage on arbitrary containers still has a minimum role that can be provided to ATs, avoiding the need for new APIs to communicate that the AT may want to change focus modes. With this, any `focusgroup` usage should be accessible by default, while still allowing for a wide range of uses.
  • Behavior Tokens and Role Mapping: The first token provided to `focusgroup` encodes the intended behavior, which can be mapped to an ARIA role, with element's having their role inferred if it did not already have a useful role. Focusgroup-managed children can also follow a similar behavior, and have their roles inferred following the concept of a "minimum aria role". 
• No Grid or 2-D Support (for now): The original implementation had some 2-D support, but the latest versions of the proposals have diverged from this implementation. I have deemed that getting the implementation to match the proposal and getting consensus on the approach is out of scope and should be tackled separately in a subsequent effort.
• Memory: Focusgroup remembers the last-focused item by default, with an option to disable memory.
• Opt-out: The focusgroup="none" opt-out is not supported in the initial implementation but is in the latest proposals. This allows for focusable children of a `focusgroup` to not participate.