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
<mailto:xiaoche...@chromium.org>,
dizha...@chromium.org <mailto: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
<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
<https://bugs.webkit.org/show_bug.cgi?id=190870>)
Could you request a signal at
https://github.com/WebKit/standards-positions
<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
<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
<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
<https://chromestatus.com/feature/5231964663578624>
Links to previous Intent discussions
https://groups.google.com/a/chromium.org/g/blink-dev/c/Fku6784p0wI/m/3MyOMTk7BwAJ
<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
<mailto: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
<mailto: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
<mailto: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>.
