Clarify UX (keyboard) and further a11y expectations for modeless dialogs

[scottaohara]

Per the dialog initial focus proposal, this unresolved comment has been moved here for further discussion. It's related to the topic of whether modeless dialogs should trap Tab key focus, but allow for users to navigate back and forth between the primary document and a modeless dialog or dialogs.

This issue could potentially replace issue 2171

@domenic:

Not really sure what to say about modeless dialogs. They're basically nonexistent on mobile, and rare on modern desktops. So it feels like the web kind of gets to define what they mean and how they're used. So probably the spec should say something about them... but what?

@aleventhal:

Google Docs on Android has a spell checker that works like a modeless dialog. You can navigate the text while keeping it open. The x button closes it. However, it does not gain initial focus, so in some ways you could just call it a panel. I guess this raises the question of, what's the difference between a modeless dialog and a panel? I think with a modeless dialog it's partly about the behavior you get for free:

1. The AT alerts the user of its existence (this behavior comes for free via a dialog start event), and
2. It has a soft navigation trap (it's possible to navigate away from it on purpose, but hard to escape it accidentally)
3. Escape key dismisses it
   In many cases an author could call something a panel, but dialogs feel more transitory. I think there seems to be an unfortunate fuzzy definition here.

@domenic:

(2) and (3) are not true in the current implementation, right? (3) we can easily add, but as discussed (2) is harder to add.
(1) is a strong differentiator.
I'll keep noodling on ideas on what to write here over the holidays, and revisit in the new year...

cc @mcking65 and @jnurthen

There are likely clarifications that the ARIA working group could assist with here, and may result in additions to role=dialog and aria-modal attribute

This is related to resolving ARIA issue 1284

[scottaohara]

Related HTML AAM issue: w3c/html-aam#377

[scottaohara]

Further discussion from the explainer pertaining to keyboard behavior:

@cookiecrook

FYI, on Mac, Control+F6 is used for otherwise unfocusable panels (dialog lite, such as an app tool palette), but few outside power users know this. Native windows within the same app can be focused with Control+Tab which is more widely known; Safari reserves this hotkey for switching browser tabs.

@aleventhal

What do you suggest? I think we need some way, even if only power users know about it. Also, WDYT of adding modeless dialogs to the landmarks?

@scottaohara:

Re: the landmark discussion. Saw an exchange on the web-a11y slack the other day where a developer was specifically asking how to give screen reader users direct access to the modeless dialogs they are using in their interface. Essentially, the advice given was "put a region inside of the dialog". So per Matt's concern that adding dialogs to the landmark would result in such dialogs being no different than regions - well anecdotally, it seems that's what's going to happen anyway without a standardization of what to do here.

Related HTML issue concerning a native mechanism to navigate landmarks: #5813

[domenic]

Regarding the question of which issues in #4184 (comment) should be considered blocking for writing up a spec of https://github.com/whatwg/html/wiki/dialog--initial-focus,-a-proposal#initial-dialog-focus-logic : I don't think this is blocking. Modeless dialogs are challenging, but giving them the same focus semantics as modal dialogs seems like a reasonable starting point. (Plus maybe the mentioned additional ability of dialog.show({ preventInitialFocus: true }).)

[domenic]

OK, I walk back that statement a little. This does block giving good advice in the conformance requirements section that was drafted at https://github.com/whatwg/html/wiki/dialog--initial-focus,-a-proposal#improving-conformance-requirements-and-examples . E.g. this issue is partially about what to substitute for that draft text where it says

Discussion topic: need more information concerning non-modal (modeless) dialogs, expected behaviors for desktop and how they may be represented on mobile web. GitHub issue 7707

and

TODO: discuss modeless dialogs, both with and without preventInitialFocus.

Given how the current spec gives zero guidance on modeless dialogs, I think it would be tolerable to keep that state of affairs, and just have a <p class="XXX"> box linking to this issue or something. But it sure would be good if we had a story here we could tell web developers, at the same time as we unveil the new story for modal dialogs.

That might be blocked on browser engineers giving a definite answer on whether they plan to implement a soft navigation trap of the sort discussed in the OP? I know Chromium has been wary of committing to that in the past, but it's probably worth a cross-browser discussion... I'll tag this as agenda+.

[josepharhar]

That might be blocked on browser engineers giving a definite answer on whether they plan to implement a soft navigation trap of the sort discussed in the OP? I know Chromium has been wary of committing to that in the past

It there's not already something in chromium that does tab trapping that we could copy, then yeah it would definitely require some work to build that functionality into FocusController. I don't think that's a reason to object to this though.

[domenic]

We discussed this at the HTML triage meeting #8162. None of the implementers present were enthused about changing the behavior of modeless dialogs.

It was noted that dialog.show() usage is quite low in Chromium (0.0012% of page views, versus 0.0260% for showModal()), so it might be worth trying to remove it, especially since we could instead encourage the upcoming popup="" API which is much clearer about how it can be integrated with various use patterns.

Even if removal is not feasible, another path would be to "deprecate" show() in spec-land, i.e. basically move it to an appendix and say authors must never use it. Then we don't have to describe any semantics or use cases for it; it's just a vestige of the platform which will never go away, but is no longer recommended, similar to <font> or document.all.

Of course, this might just be a failure of imagination and experience. Perhaps modeless dialogs are a thriving pattern on the web (separate from the pop-up use cases) and we just haven't been able to find good examples. Toward this end, we'd love any thoughts from web developers on how modeless dialogs should work, and how well dialogEl.show() works today.

In the meantime, the tentative plan is that when we expand the authoring guidance in #8199, we'll have a box saying something like

The semantics and suggested usage of modeless dialogs (i.e., those shown using show() instead of showModal()) are unclear, and we are even considering deprecating the show() method entirely. Please join the discussion in issue #7707.

[josepharhar]

Would it be helpful if I added a console message when dialog.show() is called saying that we are planning to remove it and to come here if you'd like it to stay...?

The only reason I don't want to remove it is because it's extra work for me when websites break, but if the use counter is truly below the accepted threshold or whatever then maybe it would be easy to remove.

[domenic]

I think that would only be worth doing if the group (and ideally the larger community) was affirmatively agreed to try to kill dialog.show(), and you were willing to take on the extra work of driving the deprecation and removal process. So, I think we'd need to let this thread bake for a bit first, and then you'd have to do some soul-searching about whether it's worth the time investment to help clean up the web platform in such a way :).

Historically, Chromium had a removal threshold of 0.03%, but that has been abandoned in favor of case-by-case judgments. Still, it's a nice indicator, that 0.0012% is a decent bit below that.

[domenic]

I wonder why exactly we're adding preventInitialFocus to modeless show() in #8199, if we're not sure on the exact purpose of modeless dialogs in the first place, and are thinking about removing them?

I recognize that https://github.com/whatwg/html/wiki/dialog--initial-focus,-a-proposal represents a lot of consensus-building work so I think the default path should be to keep that part of the proposal. But I am wondering if folks who were involved such as @aleventhal, @cookiecrook, @scottaohara, @mcking65, @jnurthen, etc. still believe preventInitialFocus is an important part of the proposal.

[scottaohara]

preventInitialFocus may not be as necessary anymore if a modeless dialog could be opened as a popup=manual. If specified as that and using showPopUp() to open, focus wouldn't go to the dialog by default then.

[mfreed7]

I think that would only be worth doing if the group (and ideally the larger community) was affirmatively agreed to try to kill dialog.show(), and you were willing to take on the extra work of driving the deprecation and removal process. So, I think we'd need to let this thread bake for a bit first, and then you'd have to do some soul-searching about whether it's worth the time investment to help clean up the web platform in such a way :).

Historically, Chromium had a removal threshold of 0.03%, but that has been abandoned in favor of case-by-case judgments. Still, it's a nice indicator, that 0.0012% is a decent bit below that.

Given the work on the pop-up API, which I believe is superior in a number of ways to modeless dialogs, I'm up for trying to deprecate dialog.show(). That's assuming there's appetite from other implementers and the community, of course. But I'd want to try to make that decision soon, to avoid the usage going up before we deprecate it.

[lukewarlow]

Now that popover is out in 2 (and in progress in the third) engines, is it worth discussing again the idea of at least deprecating .show()?

Edit: just noticed #9376 sorry.