Speaking with my HTML Standard spec editor hat on, I think it's appropriate for Chromium to ship this without spec changes, as Di explains.
Indeed, I'd be skeptical of changing the spec here. It might be worth opening an issue to discuss whether any changes are appropriate, but in general the spec is intentional about allowing each browser to make different choices on what it considers focusable, and in which ways things are focusable. So I'd anticipate no changes resulting from such an issue. On Tue, May 2, 2023 at 4:50 AM Di Zhang <dizha...@chromium.org> wrote: > Right - the spec leaves it up to the UA to determine what is a focusable > area. All browsers treat this a bit differently, and have typically > considered that behavior to be up to the browser. For example, Safari has a > user setting that can change what types of elements become keyboard > focusable. So I'm guessing there will be pushback to standardizing this > behavior. However, this is also why we don't believe there's a need to > change the spec for this I2S. > > Similarly, the written tests for this feature's changes are passing for > Chrome, but not the other UAs. I have removed that check from this feature > status and will update WPT accordingly. > > On Friday, April 28, 2023 at 7:08:37 AM UTC-7 Mike Taylor wrote: > >> 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/8e871d5b-f554-43df-92e7-f164a56972aan%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8e871d5b-f554-43df-92e7-f164a56972aan%40chromium.org?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/CAM0wra8dpmu3Dbykg%2BZ6e-Ka4r0r8kAiHAYmhU0WpGkEE%2B7Wzw%40mail.gmail.com.
