Focus the dialog element instead of the first focusable item #4184

dpogue · 2018-11-20T08:11:54Z

This is an attempt to address #1929, based on what seemed to be the most agreeable solution in the comment thread there (despite diverging quite significantly from the originally proposed solution in #2197).

This mirrors the change to the W3C HTML spec: w3c/html#1331 (from issue w3c/html#773, which ironically points back to #1929 here as evidence of consensus).

To recap the relevant discussion in #1929:

@stevefaulkner raises an accessibility concern about the existing dialog focusing steps

default focus on a control when a dialog is displayed is poor UX and AX in cases where the dialog contains more than a short message and an OK button.

In a follow up comment he states:

I suggest that instead of implementing a flag to override default focus on a control, change the spec so the dialog is focusable by default.
@MarcoZehe (Mozilla) adds his support:

I would also like to add my support for @stevefaulkner's and @danbeam's proposal to make the dialog focusable by default
@cookiecrook (Apple) clarifies past discussion and adds his support

As the person who was quoted, I should clarify the context. At the time, <dialog> did not receive any focus notifications in any context. It was clear that the API as written would be inaccessible for years to come. We were offering any compromise in the hope that the WHATWG editors would not forego accessibility as a requirement.

Since that time, Steve and others have pointed out the negative consequences that focusing the first control would have on screen reader and mainstream users alike. I acknowledge those points and retract that initial proposal.

I've now come around to the proposal of 1. autofocus if applied. 2. otherwise focus the dialog itself. the <dialog> element should be focusable by default

There was some statements of support from people on the Chrome team at Google, but it sounds like they are no longer involved in the project. There was hesitancy to make this change, given long history on this topic, but it doesn't sound like there's anyone defending those historic decisions (and in the case of Apple, @cookiecrook is explicitly retracting support).

Can we get consensus around this solution?

/acknowledgements.html ( diff )
/interactive-elements.html ( diff )

domenic · 2018-11-20T16:01:02Z

Hey there, thanks for writing this up. Consensus around this solution is blocked on WHATWG policy of multiple implementers planning to implement it. Right now only Chrome has a dialog implementation, and we do not support the change, so we'd need to see intent to ship for the dialog feature itself, plus this change, by two other implementers before we could consider the change to the spec.

In other words, it's best if the spec reflect the reality of the single implementation that does exist, instead of reflecting zero implementations as it would do after landing this PR.

aardrian · 2018-11-20T19:15:34Z

@domenic,

Chrome has a dialog implementation, and we do not support the change

Why not?

domenic · 2018-11-20T19:39:20Z

That was discussed in detail in the previous threads.

domenic · 2018-11-20T19:42:11Z

I forgot to mention, there's a separate question as to whether we should remove dialog from the spec entirely. For a while it looked like Gecko was going to land an implementation, but that didn't happen and now it's back to being Chrome-only, which is not great (and leads to dynamics such as this one, where we're debating having the spec match 0 vs. 1 browsers).

aardrian · 2018-11-20T20:19:03Z

@domenic,

That was discussed in detail in the previous threads.

I waded into them but could not find a discrete reason(s). If you have a comment link or similar I would appreciate it. I am only asking instead of wading in again because I suspect you know better than I where to find it.

DavidMacDonald · 2018-11-21T11:51:40Z

I support @stevefaulkner 's position. There appears to be a strong consensus building among people knowledgeable about accessibility that focus should be placed on it. I add my voice.

sefeng211 · 2020-12-04T22:18:48Z

So now Firefox has the dialog element in Nightly and pursuing to keep moving it forward, Can we merge the changes here?

domenic · 2020-12-04T22:19:48Z

No, this change does not have multi-implementer interest. See #4184 (comment)

annevk · 2020-12-07T15:38:47Z

@domenic I'm not sure I understand, there is multi-implementer interest as per #4937 (all engines want to support dialog). And as per OP both Apple and Mozilla want this change. What's lacking multi-implementer interest is Chrome's position, as far as I can tell.

domenic · 2020-12-07T16:05:40Z

And as per OP both Apple and Mozilla want this change.

I don't think we can count Apple in this calculation, as they don't support dialog at all.

annevk · 2020-12-07T16:06:38Z

But they have expressed implementer interest, which is what matters per the Working Mode, no?

domenic · 2020-12-07T16:11:46Z

I think it's more subtle than that. Expressing interest in a normative change of a feature you don't implement is not sufficient to count as implementer interest, in my opinion. Especially given our fraught history with dialog having "interest" but no implementation for many years, I believe we really need to err on the side of actual implementation interest, i.e. the working mode's

The support from implementers should be of the form “we would like to implement this soon” and not just “this seems like a reasonable idea”.

As I've mentioned before, for this reason I'm also open to removing dialog entirely until we can get a serious interoperable-across-multiple-implementers implementation. I think that would be better than Firefox implementing one thing for this focus issue, and Chrome implementing another, and the spec picking one or the other of them based on what someone chimes in from the sidelines to say they prefer.

annevk · 2020-12-07T16:14:02Z

So for Firefox this is pretty important, so I'd love it if maybe @mfreed7 @josepharhar could give some more detail as to why this cannot be changed, but Chrome appears pretty flexible on #5678.

josepharhar · 2020-12-07T16:29:59Z

I'm not aware of any reason why this can't be changed, but I'm also not an expert on the dialog element in the first place.
As I said in this comment, I'd basically have to try implementing it and hope I don't break any websites.

domenic · 2020-12-07T16:59:28Z

The reason we have been historically opposed to this in Chrome is that it is contrary to how native dialogs behave. (That is, the current specification matches native dialogs, and the proposed change fails to do so.) There is a long history here, starting in https://www.w3.org/Bugs/Public/show_bug.cgi?id=23366 and continuing in #1929, which is worth reading if the DOM team would like to change Chrome's historical policy stance on this.

sefeng211 · 2020-12-07T17:05:44Z

Good to hear that this can be possibly changed, FWIW, I'll help out with tests.

josepharhar · 2020-12-07T17:27:17Z

The reason we have been historically opposed to this in Chrome is that it is contrary to how native dialogs behave. (That is, the current specification matches native dialogs, and the proposed change fails to do so.) There is a long history here, starting in https://www.w3.org/Bugs/Public/show_bug.cgi?id=23366 and continuing in #1929, which is worth reading if the DOM team would like to change Chrome's historical policy stance on this.

Thanks, I hadn't read #1929 at all. After doing some light skimming, it sounds like the reporter decided that this shouldn't be done anymore and that #2197 could be an alternative way to fix this?

scottaohara · 2020-12-11T16:36:09Z

The reason we have been historically opposed to this in Chrome is that it is contrary to how native dialogs behave.

While I can respect the desire to keep with native behavior, web developers cram so much more / different types of content into web dialogs that matching native behavior isn't always ideal. For instance this monster <dialog> based on real content found in the wild.

The variability of where focus can start in web dialogs creates unpredictability in how they can be interacted with, and how much content will be announced, or potentially not announced to screen reader users / where focus will land and how much content can potentially scroll out of view for sighted users. Allowing focus to always start at the top of a dialog (similar to a standard web page), rather than being forced to the first focusable element, would allow all users to interact with the dialog in a consistently meaningful way.

This is a constant issue in the accessibility and usability of custom dialogs, and one that will continue to require additional effort from developers if the native dialog can't be adjusted, because of historical reasons.

If the default behavior will not be changed, then I would request that a feature (attribute?) be added to allow the dialog to receive initial focus, as there is a clear and consistently expressed desire for this behavior here and in previous threads.

josepharhar · 2020-12-11T16:39:01Z

If the default behavior will not be changed, then I would request that a feature (attribute?) be added to allow the dialog to receive initial focus, as there is a clear and consistently expressed desire for this behavior here and in previous threads.

Is this what #2197 is proposing?

scottaohara · 2020-12-11T16:47:06Z

If so, then my apologies for my slip in connecting the dots there.

(re)reading this again, if it's saying that if skipInitialFocus:true will achieve the desired behavior... focus will move to the dialog itself, unless it contained an element with the autofocus attribute, where focus would be expected to move to that element... then yes, this does seem like it would meet the 2nd-choice request to have an official way to opt-out of the native focus behavior.

Still would prefer that just be the default behavior, and use autofocus for situations where developers specifically want a particular element to be focused by default. But would appreciate that something be in place so as to point developers to what they may well need to do instead.

domenic · 2022-08-09T09:08:26Z

Status update: I've commented on all the (still open) issues mentioned in #4184 (comment) . I don't think any of them should block work on a spec PR that implements https://github.com/whatwg/html/wiki/dialog--initial-focus,-a-proposal#initial-dialog-focus-logic .

domenic · 2022-08-09T09:09:08Z

Note that a big part of such a spec PR would be the conformance requirement changes, so it should also include the changes sketched in https://github.com/whatwg/html/wiki/dialog--initial-focus,-a-proposal#improving-conformance-requirements-and-examples

Edit: and as discussed in #7707 (comment), actually there might be a slight blocker there. But we can still proceed with a draft PR for everything but modeless dialogs, I think.

This implements the changes proposed here: https://github.com/whatwg/html/wiki/dialog--initial-focus,-a-proposal#dialog-draft-text Specifically: 1. Add a parameter to dialog.show() called preventInitialFocus, which prevents the dialog focusing steps from running. 2. Make the dialog focusing steps look at sequentially focusable elements instead of any focusable element. There are additional open issues around dialog initial focus listed here: whatwg#4184 (comment) TODO add a conformance requirement about autofocus: whatwg#7709 TODO consider adding a <p class=XXX> for tab trapping: whatwg#7707

josepharhar · 2022-08-16T23:08:55Z

I opened a PR to implement the dialog initial focus proposal here: #8199
Please take a look

This has been discussed here: whatwg/html#4184 whatwg/html#8199 The gist of the changes are: 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. Fixed: 1193482 Change-Id: I1fee5981f72039a4467cbb35b2317832dd31bbea

This has been discussed here: whatwg/html#4184 whatwg/html#8199 The gist of the changes are: 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. This patch also adds "outline:none" to several WPTs because this patch causes the dialog element to become initially focused in some cases and get a focus ring. I2S: https://groups.google.com/a/chromium.org/g/blink-dev/c/CEL3wWHrTAQ Fixed: 1193482 Change-Id: I1fee5981f72039a4467cbb35b2317832dd31bbea

This has been discussed here: whatwg/html#4184 whatwg/html#8199 The gist of the changes are: 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. This patch also adds "outline:none" to several WPTs because this patch causes the dialog element to become initially focused in some cases and get a focus ring. I2S: https://groups.google.com/a/chromium.org/g/blink-dev/c/CEL3wWHrTAQ Fixed: 1193482 Change-Id: I1fee5981f72039a4467cbb35b2317832dd31bbea Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3984630 Commit-Queue: Joey Arhar <jarhar@chromium.org> Reviewed-by: Mason Freed <masonf@chromium.org> Cr-Commit-Position: refs/heads/main@{#1100024}

This has been discussed here: whatwg/html#4184 whatwg/html#8199 The gist of the changes are: 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. This patch also adds "outline:none" to several WPTs because this patch causes the dialog element to become initially focused in some cases and get a focus ring. I2S: https://groups.google.com/a/chromium.org/g/blink-dev/c/CEL3wWHrTAQ Fixed: 1193482 Change-Id: I1fee5981f72039a4467cbb35b2317832dd31bbea Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3984630 Commit-Queue: Joey Arhar <jarhar@chromium.org> Reviewed-by: Mason Freed <masonf@chromium.org> Cr-Commit-Position: refs/heads/main@{#1100024}

… a=testonly Automatic update from web-platform-tests Implement dialog initial focus proposal This has been discussed here: whatwg/html#4184 whatwg/html#8199 The gist of the changes are: 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. This patch also adds "outline:none" to several WPTs because this patch causes the dialog element to become initially focused in some cases and get a focus ring. I2S: https://groups.google.com/a/chromium.org/g/blink-dev/c/CEL3wWHrTAQ Fixed: 1193482 Change-Id: I1fee5981f72039a4467cbb35b2317832dd31bbea Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3984630 Commit-Queue: Joey Arhar <jarhar@chromium.org> Reviewed-by: Mason Freed <masonf@chromium.org> Cr-Commit-Position: refs/heads/main@{#1100024} -- wpt-commits: 95f9b15d9aad3354f440e4e4cced5ccc405b0069 wpt-pr: 36831

This has been discussed here: whatwg/html#4184 whatwg/html#8199 The gist of the changes are: 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. This patch also adds "outline:none" to several WPTs because this patch causes the dialog element to become initially focused in some cases and get a focus ring. I2S: https://groups.google.com/a/chromium.org/g/blink-dev/c/CEL3wWHrTAQ Fixed: 1193482 Change-Id: I1fee5981f72039a4467cbb35b2317832dd31bbea Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3984630 Commit-Queue: Joey Arhar <jarhar@chromium.org> Reviewed-by: Mason Freed <masonf@chromium.org> Cr-Commit-Position: refs/heads/main@{#1100024}

annevk added normative change needs implementer interest Moving the issue forward requires implementers to express interest accessibility Affects accessibility labels Nov 20, 2018

dpogue mentioned this pull request May 26, 2020

Add notes explaining how <dialog>.showModal() focuses #5534

Merged

annevk added the topic: dialog The <dialog> element label May 29, 2020

Base automatically changed from master to main January 15, 2021 07:57

dpogue closed this Mar 26, 2021

dpogue force-pushed the dialog-focusing branch from 50f98c1 to e8417e5 Compare March 26, 2021 14:25

Focus the dialog instead of the first item

b9ad26b

dpogue reopened this Mar 26, 2021

domenic mentioned this pull request Aug 9, 2022

Initial focus placement for dialog element: terminology for first-focusable vs first-tabbable #7710

Open

josepharhar mentioned this pull request Aug 16, 2022

Implement dialog initial focus proposal #8199

Merged

3 tasks

past mentioned this pull request Aug 19, 2022

Upcoming HTML standard issue triage meeting on 8/18/2022 (new time!) #8162

Closed

dmitriid mentioned this pull request Aug 28, 2022

[templates] Ensure that template instantiation actually improves the platform WICG/webcomponents#704

Open

chromium-wpt-export-bot mentioned this pull request Nov 5, 2022

Implement dialog initial focus proposal web-platform-tests/wpt#36831

Merged

domenic closed this in a9f103c Jan 26, 2023

afercia mentioned this pull request Sep 21, 2023

Allow Modal to place focus on first element within contents via new API WordPress/gutenberg#54590

Merged

afercia mentioned this pull request Oct 19, 2023

Image: Improve focus management in lightbox WordPress/gutenberg#55428

Merged

bganotoo mentioned this pull request Jan 25, 2024

Default focus for <dialog> no longer accurate? mdn/content#31917

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Focus the dialog element instead of the first focusable item #4184

Focus the dialog element instead of the first focusable item #4184

dpogue commented Nov 20, 2018 •

edited by pr-preview bot

Loading

domenic commented Nov 20, 2018 •

edited

Loading

aardrian commented Nov 20, 2018

domenic commented Nov 20, 2018

domenic commented Nov 20, 2018

aardrian commented Nov 20, 2018

DavidMacDonald commented Nov 21, 2018

sefeng211 commented Dec 4, 2020

domenic commented Dec 4, 2020 •

edited

Loading

annevk commented Dec 7, 2020

domenic commented Dec 7, 2020

annevk commented Dec 7, 2020

domenic commented Dec 7, 2020

annevk commented Dec 7, 2020

josepharhar commented Dec 7, 2020

domenic commented Dec 7, 2020

sefeng211 commented Dec 7, 2020

josepharhar commented Dec 7, 2020

scottaohara commented Dec 11, 2020

josepharhar commented Dec 11, 2020

scottaohara commented Dec 11, 2020 •

edited

Loading

domenic commented Aug 9, 2022

domenic commented Aug 9, 2022 •

edited

Loading

josepharhar commented Aug 16, 2022

Focus the dialog element instead of the first focusable item #4184

Focus the dialog element instead of the first focusable item #4184

Conversation

dpogue commented Nov 20, 2018 • edited by pr-preview bot Loading

domenic commented Nov 20, 2018 • edited Loading

aardrian commented Nov 20, 2018

domenic commented Nov 20, 2018

domenic commented Nov 20, 2018

aardrian commented Nov 20, 2018

DavidMacDonald commented Nov 21, 2018

sefeng211 commented Dec 4, 2020

domenic commented Dec 4, 2020 • edited Loading

annevk commented Dec 7, 2020

domenic commented Dec 7, 2020

annevk commented Dec 7, 2020

domenic commented Dec 7, 2020

annevk commented Dec 7, 2020

josepharhar commented Dec 7, 2020

domenic commented Dec 7, 2020

sefeng211 commented Dec 7, 2020

josepharhar commented Dec 7, 2020

scottaohara commented Dec 11, 2020

josepharhar commented Dec 11, 2020

scottaohara commented Dec 11, 2020 • edited Loading

domenic commented Aug 9, 2022

domenic commented Aug 9, 2022 • edited Loading

josepharhar commented Aug 16, 2022

dpogue commented Nov 20, 2018 •

edited by pr-preview bot

Loading

domenic commented Nov 20, 2018 •

edited

Loading

domenic commented Dec 4, 2020 •

edited

Loading

scottaohara commented Dec 11, 2020 •

edited

Loading

domenic commented Aug 9, 2022 •

edited

Loading