On 4/27/23 5:28 PM, Di Zhang wrote:
Contact emails
h...@chromium.org, xiaoche...@chromium.org, dizha...@chromium.org
Explainer
None
Specification
None
What's the reason for not having a spec? Is the idea that this is
covered by this definition of a "focusable area": "the element is
determined by the user agent to be focusable"
If we have multi-vendor alignment, maybe we can be more explicit than that?
(https://html.spec.whatwg.org/#focusable-area)
Design docs
None
Summary
Improves accessibility by making scroll containers focusable using
sequential focus navigation. Today, the tab key doesn't focus
scrollers unless tabIndex is explicitly set to 0 or more. By making
scrollers focusable by default, users who can't (or don't want to) use
a mouse will be able to focus clipped content using a keyboard's tab
and arrow keys. This behavior is enabled only if the scroller does not
contain any keyboard focusable children. This logic is necessary so we
don't cause regressions for existing focusable elements that might
exist within a scroller like a <textarea>.
Blink component
Blink>HTML>Focus
<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EHTML%3EFocus>
Search tags
tab key <https://chromestatus.com/features#tags:tab%20key>, keyboard
focus <https://chromestatus.com/features#tags:keyboard%20focus>,
sequential navigation
<https://chromestatus.com/features#tags:sequential%20navigation>
TAG review
None
TAG review status
Not applicable
Risks
Interoperability and Compatibility
This is a change in behavior, but already matches what Firefox is
doing (have scroller be focusable by default). Low compatibility risk
since this default behavior is only enabled if the scroller doesn't
have any focusable children.
/Gecko/: Shipped/Shipping Chrome behavior is slightly different since
we are checking if any scroller child is focusable. This is to avoid
regression on existing focus sequences.
/WebKit/: No signal (https://bugs.webkit.org/show_bug.cgi?id=190870)
Could you request a signal at
https://github.com/WebKit/standards-positions? It's hard to know if
Ryosuke's comment is still valid since he made it.
/Web developers/: Positive
(https://twitter.com/simevidas/status/1444033718742667270)
/Other signals/:
Ergonomics
There are no other platform APIs this feature will be used in tandem
with. It will not be hard for Chrome to maintain good performance.
Activation
It will not be challenging for developers to take advantage of this
feature immediately.
Security
There are no security risks, this is a change for keyboard focusing
behavior.
WebView application risks
Does this intent deprecate or change behavior of existing APIs, such
that it has potentially high risk for Android WebView-based applications?
This is not high risk for WebView.
Debuggability
This is a change to focus navigation and DevTools does not offer
debugging support for this behavior.
Will this feature be supported on all six Blink platforms
(Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes
Is this feature fully tested by web-platform-tests
<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?
Yes
Mind giving a link to the tests?
Flag name
KeyboardFocusableScrollers
Requires code in //chrome?
False
Tracking bug
https://bugs.chromium.org/p/chromium/issues/detail?id=1040141
Availability expectation
Firefox already implements (a variant of this). If we succeed and
don't break websites, Safari is more likely to follow suit.
Adoption expectation
This is a default behavior change and websites don't need to make changes.
Non-OSS dependencies
Does the feature depend on any code or APIs outside the Chromium open
source repository and its open-source dependencies to function?
This feature does not depend on any APIs outside the chromium open
source repository.
Estimated milestones
Shipping on desktop 114
Shipping on Android 114
Shipping on WebView 114
Anticipated spec changes
Open questions about a feature may be a source of future web compat or
interop issues. Please list open issues (e.g. links to known github
issues in the project for the feature specification) whose resolution
may introduce web compat/interop risk (e.g., changing to naming or
structure of the API in a non-backward-compatible way).
This change is not specced yet. If this succeed, we will try to get it
specced.
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5231964663578624
Links to previous Intent discussions
https://groups.google.com/a/chromium.org/g/blink-dev/c/Fku6784p0wI/m/3MyOMTk7BwAJ
This intent message was generated by Chrome Platform Status
<https://chromestatus.com/>.
--
You received this message because you are subscribed to the Google
Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BSS7eBXci2n6rVdpLwWXgOmRrmkE%2BaxQGbq3dBwpmnyHOK9aA%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BSS7eBXci2n6rVdpLwWXgOmRrmkE%2BaxQGbq3dBwpmnyHOK9aA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to the Google Groups
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5b85862d-4fba-dd11-f1e6-421e8e032950%40chromium.org.
