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.