Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
wants to merge 1 commit into
base: master
from

Conversation

5 participants
@dpogue
Copy link

dpogue commented Nov 20, 2018

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:

  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

This comment has been minimized.

Copy link
Member

domenic commented Nov 20, 2018

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

This comment has been minimized.

Copy link

aardrian commented Nov 20, 2018

@domenic,

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

Why not?

@domenic

This comment has been minimized.

Copy link
Member

domenic commented Nov 20, 2018

That was discussed in detail in the previous threads.

@domenic

This comment has been minimized.

Copy link
Member

domenic commented Nov 20, 2018

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

This comment has been minimized.

Copy link

aardrian commented Nov 20, 2018

@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

This comment has been minimized.

Copy link

DavidMacDonald commented Nov 21, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.