Thanks Domenic, that's helpful and makes sense to me. It's perhaps whether this is a "web exposed" change or not.
This sounds pretty safe to experiment with to me. Di please make sure behavior change is done behind a flag <https://chromium.googlesource.com/chromium/src/+/main/docs/flag_guarding_guidelines.md#When-is-a-flag-required> so we can 'kill switch' it if needed. Perhaps the biggest compatibility risk here is the impact on assistive technology use cases? That's not something I feel equipped to have any judgement around. Have you talked with anyone in the accessibility team about this? Do we have any data or anecdotes on sites setting tabindex:0 on scrollers? Perhaps if that's already somewhat common place then that could reduce any fear dramatically? I have a vague memory that "element is focusable" may be used in the tab highlighting algorithm. It may be worth a quick check to ensure that this doesn't cause highlights to show up when tapping on a scrollable region that has no other tap highlight candidates. I can help point you at the right code / people if desired. Rick On Mon, May 8, 2023 at 3:51 AM Domenic Denicola <dome...@chromium.org> wrote: > 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra8dpmu3Dbykg%2BZ6e-Ka4r0r8kAiHAYmhU0WpGkEE%2B7Wzw%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/CAFUtAY-v2%3D4HXddcna6KVcU5uwb97GukzPoK%3DnaHe1G73xFF9A%40mail.gmail.com.
