Intent to Ship: Updated dialog initial focus algorithm

160 views
Skip to first unread message

Joey Arhar

unread,
Jan 18, 2023, 6:00:26 PM1/18/23
to blink-dev

Contact emails

jar...@chromium.org

Specification

https://github.com/whatwg/html/pull/8199

Summary

Some changes are being made to which element is selected to get focus when a dialog element is opened: 1. Make the dialog focusing steps look at keyboard focusable elements instead of any focusable element. 2. Make the dialog element itself get focus if it has the autofocus attribute set. 3. Make the dialog element itself get focus as a fallback instead of focus being "reset" to the body element.



Blink component

Blink>HTML>Dialog

TAG review

None

TAG review status

Not applicable

Risks



Interoperability and Compatibility

If a website affected by this change absolutely needs the old element to be focused, they would likely need to add the autofocus attribute to it. If by some chance this causes a really bad breakage, I can disable it via finch. I don't believe negative effects are likely since this new behavior was thoroughly thought out over the last year by accessibility experts.



Gecko: No signal (https://github.com/mozilla/standards-positions/issues/734)

WebKit: No signal (https://github.com/WebKit/standards-positions/issues/123)

Web developers: No signals

Other signals:

Ergonomics

This change will not be used in tandem with other platform APIs.



Activation

It will not be challenging for developers to take advantage of this change, and no polyfills/outreach is needed.



Security

This change has no security considerations/risks.



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?



Debuggability

Dialog initial focus doesn't have any special DevTools support and I don't think it needs any.



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 name

--enable-features=DialogNewFocusBehavior

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1193482

Estimated milestones

111



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



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/4675914745511936

This intent message was generated by Chrome Platform Status.

Rick Byers

unread,
Jan 24, 2023, 10:41:38 AM1/24/23
to Joey Arhar, blink-dev
Looks like showing dialog elements is at around 0.04% of page loads, so that's an upper bound of the compat risk here, right? The severity of breakage for focus not being what the developer wanted seems quite low, and ease of adaptability seems high. Also it seems clear there will be a significant net accessibility benefit to this change. Thanks for adding the finch kill-switch just in case we're wrong about all this.

LGTM1

--
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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK6btwKVyLctXm%2B7UNenRyKsRNpY%2BrxWF_4LuYn6rJdYbu_bQQ%40mail.gmail.com.

Philip Jägenstedt

unread,
Jan 24, 2023, 11:52:35 AM1/24/23
to Rick Byers, Joey Arhar, blink-dev
Is https://github.com/whatwg/html/pull/8199 blocked mainly on implementer interest?

Do other browsers exactly match the behavior before this spec change, or is it more complicated than that? What I'm getting at is whether we have confidence that we'll have eventual interop on the new behavior.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY9baok4j46gxQeJDJNLpHqEO3KLeEvFarCeKWj_XYj-JA%40mail.gmail.com.

Joey Arhar

unread,
Jan 25, 2023, 12:42:39 AM1/25/23
to Philip Jägenstedt, Rick Byers, blink-dev
> Is https://github.com/whatwg/html/pull/8199 blocked mainly on implementer interest?

Yes it looks that way

> Do other browsers exactly match the behavior before this spec change, or is it more complicated than that? What I'm getting at is whether we have confidence that we'll have eventual interop on the new behavior.

Yes, we currently have interop.
People from the other browsers discussed changing the initial focus behavior quite a bit in this issue, so I feel confident that they will also implement the new behavior assuming they approve of the new spec.

Yoav Weiss

unread,
Jan 25, 2023, 6:15:56 AM1/25/23
to blink-dev, Joey Arhar, Rick Byers, blink-dev, Philip Jägenstedt
LGTM2 for the reasons Rick pointed out. 
On Wednesday, January 25, 2023 at 6:42:39 AM UTC+1 Joey Arhar wrote:
> Is https://github.com/whatwg/html/pull/8199 blocked mainly on implementer interest?

Yes it looks that way

> Do other browsers exactly match the behavior before this spec change, or is it more complicated than that? What I'm getting at is whether we have confidence that we'll have eventual interop on the new behavior.

Yes, we currently have interop.
People from the other browsers discussed changing the initial focus behavior quite a bit in this issue, so I feel confident that they will also implement the new behavior assuming they approve of the new spec.

It won't be hard for us to change course if the discussion with other vendors would cause the spec change to land as slightly different, right?
 

On Tue, Jan 24, 2023 at 8:52 AM Philip Jägenstedt <foo...@chromium.org> wrote:
Is https://github.com/whatwg/html/pull/8199 blocked mainly on implementer interest?

Do other browsers exactly match the behavior before this spec change, or is it more complicated than that? What I'm getting at is whether we have confidence that we'll have eventual interop on the new behavior.

On Tue, Jan 24, 2023 at 4:41 PM Rick Byers <rby...@chromium.org> wrote:
Looks like showing dialog elements is at around 0.04% of page loads, so that's an upper bound of the compat risk here, right? The severity of breakage for focus not being what the developer wanted seems quite low, and ease of adaptability seems high. Also it seems clear there will be a significant net accessibility benefit to this change. Thanks for adding the finch kill-switch just in case we're wrong about all this.

LGTM1

On Wed, Jan 18, 2023 at 6:00 PM Joey Arhar <jar...@chromium.org> wrote:


Summary

Some changes are being made to which element is selected to get focus when a dialog element is opened: 1. Make the dialog focusing steps look at keyboard focusable elements instead of any focusable element. 2. Make the dialog element itself get focus if it has the autofocus attribute set. 3. Make the dialog element itself get focus as a fallback instead of focus being "reset" to the body element.



Blink componentBlink>HTML>Dialog

TAG reviewNone

TAG review statusNot applicable


Risks


Interoperability and Compatibility

If a website affected by this change absolutely needs the old element to be focused, they would likely need to add the autofocus attribute to it. If by some chance this causes a really bad breakage, I can disable it via finch. I don't believe negative effects are likely since this new behavior was thoroughly thought out over the last year by accessibility experts.



Gecko: No signal (https://github.com/mozilla/standards-positions/issues/734)

WebKit: No signal (https://github.com/WebKit/standards-positions/issues/123)

Web developers: No signals

Other signals:

Ergonomics

This change will not be used in tandem with other platform APIs.



Activation

It will not be challenging for developers to take advantage of this change, and no polyfills/outreach is needed.



Security

This change has no security considerations/risks.



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?



Debuggability

Dialog initial focus doesn't have any special DevTools support and I don't think it needs any.



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 name--enable-features=DialogNewFocusBehavior

Requires code in //chrome?False



Estimated milestones

111



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



Link to entry on the Chrome Platform Statushttps://chromestatus.com/feature/4675914745511936


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+unsubscribe@chromium.org.

--
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+unsubscribe@chromium.org.

Joey Arhar

unread,
Jan 26, 2023, 1:54:20 PM1/26/23
to Yoav Weiss, blink-dev, Rick Byers, Philip Jägenstedt

> It won't be hard for us to change course if the discussion with other vendors would cause the spec change to land as slightly different, right?

Yes. If the WebKit signal changes things then I'll just update the behavior.

Chris Harrelson

unread,
Feb 1, 2023, 11:08:43 AM2/1/23
to Joey Arhar, Yoav Weiss, blink-dev, Rick Byers, Philip Jägenstedt
LGTM3

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK6btwKjekCKGnnHnke8Sqx5f4m0MM0R_qp%2BN%3D2jQyToxh59rQ%40mail.gmail.com.
Reply all
Reply to author
Forward
0 new messages