LGTM2 On Wed, May 10, 2023 at 5:50 PM Mike Taylor <miketa...@chromium.org> wrote:
> LGTM1 > On 5/9/23 6:15 PM, Di Zhang wrote: > > Yes, this change is flagged behind the feature KeyboardFocusableScrollers > (disabled by passing > `--disable-blink-features=KeyboardFocusableScrollers`). > > We have looped in aleventhal@ for similar accessibility concern. Aaron is > the one who implemented the Keyboard Focusable Scrollers feature on Gecko > years ago. > This feature (minus the "not contain any keyboard focusable children" rule) > has existed in Firefox for +18 years now without any issue. Since assistive > technology (for example screen readers) are using the same code for Firefox > and Chrome, this should be low risk. > > > 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. > Just to clarify, when you mention "tab highlighting algorithm", do you > mean showing the orange focus ring when on mobile devices? I just tried > with the feature on and off. In both cases, tapping doesn't show focus (no > focus ring). As for using tab navigation, I see the same behavior as on the > web. If feature is on, then an orange focus ring will show on the scroller. > If my understanding is wrong, please point me to the right code / people. > Thank you > > > > > On Monday, May 8, 2023 at 4:00:23 AM UTC-7 Rick Byers wrote: > >> 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/37e97d89-ebe6-5403-d303-1bedb2e89524%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/37e97d89-ebe6-5403-d303-1bedb2e89524%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/CAARdPYeJSTSpo9Me-fyG1wSpmft1VnOKFSVqWYpGRdq19mqXEQ%40mail.gmail.com.
