Intent to Prototype: Focusgroup
Benjamin Beaudry
Contact emails
bebe...@microsoft.com
Explainer
Summary
The Focusgroup feature will facilitate keyboard focus navigation using the keyboard arrow keys among a set of focusable elements.
Blink component
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
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
Estimated milestones
No milestones specified
Link to entry on the Chrome Platform Status
Jacques Newman
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.
- 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.
