Re: [blink-dev] Intent to Ship: Keyboard-focusable scroll containers

[Daniel Bratell]

Make that LGTM3 from me. Good luck shipping!

/Daniel

On 2023-05-10 17:52, Philip Jägenstedt wrote:

LGTM2

On Wed, May 10, 2023 at 5:50 PM Mike Taylor  
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


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

Re: [blink-dev] Intent to Ship: Keyboard-focusable scroll containers

[Philip Jägenstedt]

LGTM2

On Wed, May 10, 2023 at 5:50 PM Mike Taylor  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
>> 
>> 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 
>> 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  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 

Re: [blink-dev] Intent to Ship: Keyboard-focusable scroll containers

[Daniel Bratell]

LGTM2

/Daniel

On 2023-05-10 17:50, Mike Taylor 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


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

Re: [blink-dev] Intent to Ship: Keyboard-focusable scroll containers

[Mike Taylor]

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


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

Re: [blink-dev] Intent to Ship: Keyboard-focusable scroll containers

[Di Zhang]

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

Re: [blink-dev] Intent to Ship: Keyboard-focusable scroll containers

[Rick Byers]

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

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 
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  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
>>> .
>>>
>>>
>>> Blink component Blink>HTML>Focus
>>> 
>>>
>>> Search tags tab key , 
>>> keyboard
>>> focus , sequential
>>> navigation
>>> 
>>>
>>> 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 

Re: [blink-dev] Intent to Ship: Keyboard-focusable scroll containers

[Domenic Denicola]

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  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
>> .
>>
>>
>> Blink component Blink>HTML>Focus
>> 
>>
>> Search tags tab key , 
>> keyboard
>> focus , sequential
>> navigation
>> 
>>
>> 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
>> 
>> ? 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
>>

Re: [blink-dev] Intent to Ship: Keyboard-focusable scroll containers

[Di Zhang]

 

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 
> . 
>
>
> Blink component Blink>HTML>Focus 
> 
>
> Search tags tab key , 
> keyboard 
> focus , sequential 
> navigation 
> 
>
> 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 
> 
> ? 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 

Re: [blink-dev] Intent to Ship: Keyboard-focusable scroll containers

[Mike Taylor]

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 .




Blink component

Blink>HTML>Focus 




Search tags

tab key , keyboard 
focus , 
sequential navigation 




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

?

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 

[blink-dev] Intent to Ship: Keyboard-focusable scroll containers

[Di Zhang]

Contact emailsh...@chromium.org, xiaoche...@chromium.org,
dizha...@chromium.org

ExplainerNone

Specification
None

Design docsNone

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
.


Blink componentBlink>HTML>Focus


Search tagstab key , keyboard
focus , sequential
navigation 

TAG reviewNone

TAG review statusNot 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)

*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

?Yes

Flag nameKeyboardFocusableScrollers

Requires code in //chrome?False

Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1040141

Availability expectationFirefox already implements (a variant of this). If
we succeed and don't break websites, Safari is more likely to follow suit.

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

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