Focus the dialog element instead of the first focusable item

[dpogue]

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: https://github.com/w3c/html/pull/1331 (from issue https://github.com/w3c/html/issues/773, which ironically points back to #1929 here as evidence of consensus).

To recap the relevant discussion in #1929:

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

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

3. @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]

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]

@domenic,

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

Why not?

[domenic]

That was discussed in detail in the previous threads.

[domenic]

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]

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

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]

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

[domenic]

No, this change does not have multi-implementer interest. See https://github.com/whatwg/html/pull/4184#issuecomment-440326010

[annevk]

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

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]

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

[domenic]

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]

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]

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]

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 https://github.com/whatwg/html/issues/1929, which is worth reading if the DOM team would like to change Chrome's historical policy stance on this.

[sefeng211]

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

[josepharhar]

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 https://github.com/whatwg/html/pull/2197 could be an alternative way to fix this?

[scottaohara]

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]

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 https://github.com/whatwg/html/pull/2197 is proposing?

[scottaohara]

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.

[sefeng211]

We are trying to make this happen :)

• [x] At least two implementers are interested (and none opposed):
  • Firefox is interested
  • Chrome sounds also flexible for this change
• [x] Tests are written and can be reviewed and commented upon at:
  • Tests are included in this Firefox patch: https://phabricator.services.mozilla.com/D109950, will be merged automatically to WPT once it's landed.
• [x] Implementation bugs are filed:
  • Chrome: https://bugs.chromium.org/p/chromium/issues/detail?id=1193482
  • Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1701230

ping @domenic @josepharhar

[domenic]

Although @josepharhar's team is the one making the final call here for Chromium, and not me, I continue to believe this is the wrong path as I stated a few months ago in https://github.com/whatwg/html/pull/4184#issuecomment-740047054, as it diverges <dialog> from native dialogs. Something like #2197 seems more acceptable instead of breaking the default behavior.

[domenic]

Also, recall that dialogs are not focusable areas today, so the change here would be pretty large with more serious compat implications. #1929 digs into that more, and also discusses how <dialog> is poorly suited for cases like menus (where not focusing the first-focusable child makes sense; instead the menu element should be focusable).

[sefeng211]

I didn't go through the webkit's discussion because it was a long thread.....However, it looks like the recent agreement on that is this comment made @cookiecrook, so I don't think we still have any concerns left with native dialogs.

Also, note that in the past, we had reached a general consensus about this change in #1929, although dbeam had moved on from working on Chrome.

[domenic]

In general we shouldn't rely on year-old affirmations from people who may or may not still be working on the relevant area of code; if you're trying to land a change now, it's good idea to get interest now.

[annevk]

@josepharhar could you please provide an update for Chrome? @cookiecrook has your thinking on this perhaps changed since https://github.com/whatwg/html/pull/4184#issue-232225311 or do you still agree with that? As I understand it Firefox's accessibility team still thinks this is the way to go.

[domenic]

At the last triage meeting we discussed this issue and the conclusion was that we needed a clearer statement of use cases and user journeys, instead of focusing on this specific solution. In particular we want to compare those user journeys to native dialogs (of the type Firefox already implements in its native UI) so we could compare how Firefox and others solve such journeys for native dialogs with any proposed solution for the HTML element. So the ball is currently in @sefeng211's court to collate those for the group.

[josepharhar]

I'll defer to domenic on this one. I don't have much context/insight on this, and the only reason I will say no is if the change breaks existing tests/websites.

[melanierichards]

At the last HTML triage meeting, folks requested input on this issue from accessibility folks at Microsoft. After some discussion, our group's conclusion was that:

• With any choice, there are tradeoffs and differing user preferences. We're aiming for the most reasonable baseline/default.
• If dialog was used strictly in the sense of OS platform dialogs (e.g. some string and OK/cancel buttons), it would be preferable and expected to place focus on one of those commands.
• But because the HTML dialog element can have varying different content models in active use, and because of potential accessibility issues, it would be best to set focus on the dialog itself by default. An exemplary accessibility issue would be a scenario where a screen magnifier user is sent to some random link in a long and complex dialog, and loses context or even awareness of contents that come before that first focusable element.
• Web developers can and should think critically about (and test!) whether setting focus to the dialog is the best experience for their given use case, and can use available primitives to send focus elsewhere as appropriate. But for the swath of web developers who haven't put in this level of consideration, sending focus to the dialog itself is a preferable baseline/default. (Aside: perhaps a new delegatesfocus attribute would be helpful here for developers who know the first focusable element should be appropriate for their suite of dialogs.)

For transparency, this discussion was not based on independent user research tailored to this question, but on prior art/knowledge in the space. People with disabilities (and users of assistive technologies) were participants in the discussion, and their opinions are their own vs necessarily representative of all people with their disability. :)

[domenic]

Hi @melanierichards, it's helpful that you got an opinion on the desired end state out of your internal stakeholders, but the next steps we needed were a better sense of the use cases and user journeys.

You hinted at such use cases with "But because the HTML dialog element can have varying different content models in active use", contrasting them with (what the dialog element is currently designed for) "If dialog was used strictly in the sense of OS platform dialogs (e.g. some string and OK/cancel buttons)".

Could you or the stakeholders you consulted expand upon such "dialogs" that don't match the OS platform/HTML spec usage of the term, what the desired user experience is in such situations, and how native apps (on mobile or desktop) behave in those situations? A concrete example would be ideal, e.g. some non-dialog "dialog" that appears in Microsoft Office perhaps, and what the focus behavior is for it. Then, once we have such a concrete use case, we could continue from the place where we left off, and discuss whether <dialog> with non-OS-dialog focus behavior is the best way to bring that pattern to the web, or whether there are other solutions for the use case.