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>.
