tracking issue for <dialog> & role=dialog

[jnurthen]

Filed as a tracking issue for whatwg/html#4184

Agenda for Mar 24 2022 is to discuss Initial Focus

[aleventhal]

A few of us (including myself, @scottaohara from Microsoft. @jcsteh from Mozilla, and others) got together to work out the issues with initial dialog focus. There were reasonable concerns. We gathered everything together and ended up with this proposal: https://github.com/whatwg/html/wiki/dialog--initial-focus,-a-proposal

The discussion has been very valuable. Our end goal is to pull improvements from this discussion into HTML and ARIA specs and and implementations. ARIA and HTML should be aligned, such that <dialog> and role=dialog result in similiar behavior.

All browsers are currently shipping some form of initial focus in dialog, using some version/concept of "first focusable descendant". Firefox was satisfied with the direction of the discussion, in terms of improving existing behavior, and as a result, they started shipping in Firefox 98. Safari 15.4 and Chrome/Edge already ship as well.

The discussion needs to continue on these issues we uncovered:

AT support:

• Should modeless dialogs be treated as a landmark
• Should platform APIs provide a dialog open event
• Should platform APIs provide a means to determine whether a dialog is modal or non-modal? HTML-AAM 377
• Should guidance be provided on what screen readers should announce when a dialog opens (they tend to read up to the current focus, but have slightly different heuristics)

Improving keyboard accessibility of non-modal dialogs:

• Tab trapping Should <dialog> actually create a "control group" for focus? whatwg/html#2171
• Dialog closing keystrokes such as Escape: Enable support for<dialog> to be dismissed using the back button whatwg/html#5667
• Pane switching keystrokes such as F6 (or Ctrl+F6 on Mac): Clarify UX (keyboard) and further a11y expectations for modeless dialogs whatwg/html#7707

[scottaohara]

this issue seems to supersede #1284

[aleventhal]

Results of deep dive call.

AT support:
Should modeless dialogs be treated as a landmark — still controversial

Should platform APIs provide a dialog open event — this is one possible way of implementing UX for non-modal dialogs so that screen readers can announcement them and magnifiers can auto pan to them, even when they don't get focus. We should check with AT vendors on each platform whether they want it, and whether existing events are enough. Also look at possibility of close event. However, platform APIs generally already inform ATs of document mutations, and the ATs can simply look for role=dialog. Therefore, this is likely not necessary for most platforms.

Should platform APIs provide a means to determine whether a dialog is modal or non-modal? w3c/html-aam#377 —MAY, whenever possible, although some platforms do not have an easy way to add this property, and ATs could do this via heuristic by checking whether the document has any other children other than the dialog. Because of this, it may not always be worth adding the property on every platform — so, will be decided on a platform-by-platform basis.

Should guidance be provided on what screen readers should announce when a dialog opens (they tend to read up to the current focus, but have slightly different heuristics)
Consensus is that ARIA spec will say something to the effect of:
aria-describedby/description on dialog provides way to override initial description
otherwise AT applies heuristic that is roughly equivalent to reading up to the first focus
ARIA AT will work to build consensus around the precise heuristic

Improving keyboard accessibility of non-modal dialogs:
Focus does not automatically move into non-modal unless autofocus is used — YES, will go into HTML spec.
Tab trapping whatwg/html#2171 — Yes, trap tabs, only tabs, F6 still works
Dialog closing keystrokes such as Escape: whatwg/html#5667 — Yes, when focus is inside. But not when focus is outside, because there can be multiple non-modals. Spec should show code on how to override.
Pane switching keystrokes such as F6 (or Ctrl+F6 on Mac): whatwg/html#7707 — Yes, add to F6 cycle in browser.

New question cam up: what even is a dialog? Is it transitory by definition? What is the difference between dialog and complementary?

[aleventhal]

@jcsteh can you look at my previous comment and give some input? We'd like to be efficient about resolving these. One we're struggling with is whether to specify that non-modal dialogs are landmarks. @mcking65 says no, but TBH I'm not sure what the downside is.

[jnurthen]

Please add non-modal dialog use cases at https://github.com/w3c/aria/wiki/Non-modal-dialog-use-cases

[jcsteh]

AT support: Should modeless dialogs be treated as a landmark — still controversial

This seems reasonable to me; there shouldn't be too many on a page and a user may well wish to jump ton one quickly. On the other hand, specifying that something is a landmark makes it a requirement that ATs treat dialog the same as other landmarks. In contrast, an AT may wish to treat dialogs separately; e.g. perhaps they have some other command for jumping to dialogs/pop-ups.

@mcking65 says no, but TBH I'm not sure what the downside is.

@mcking65, could you summarise your concerns here?

Should platform APIs provide a dialog open event — this is one possible way of implementing UX for non-modal dialogs so that screen readers can announcement them and magnifiers can auto pan to them, even when they don't get focus. We should check with AT vendors on each platform whether they want it, and whether existing events are enough.

Firefox + NVDA have used the alert role and event a little more broadly than the spec for role="alert" for many years now, I think before role="alert" was even fully specified. This is used for non-modal notifications. These are given a role of alert (to differentiate them from "dialogs", which users tend to think of as modal) and fire the alert event when they appear. When this happens, NVDA reports not only the description of the alert, but also any focusable descendants. This allows buttons with shortcut keys to be reported so that the user can activate the button without even having to focus the notification.

On Windows (and perhaps ATK), I wonder if we could use the alert event in a similar way. To conform with the spec, this would have to be broadened to support elements with a role of dialog which don't have the modal state.

Should platform APIs provide a means to determine whether a dialog is modal or non-modal?
...
Should guidance be provided on what screen readers should announce when a dialog opens

Related to the above, one concern I have is how most screen reader users will understand non-modal dialogs. My feeling is that when users hear a "dialog" get announced, they will think of a modal dialog and assume it has focus. This is because the distinction between modal and non-modal dialogs is far more subtle in native apps; even non-modal dialogs get focus, so they're effectively the same as modal dialogs. There is definitely a concept of pop-ups that get reported but do not get focus, but these are usually called alerts or notifications. I'm concerned that a user won't know what a "non-modal dialog" is and won't understand that it doesn't necessarily get focus even if it is reported.

Personally, I'd prefer to see non-modal dialogs called alerts for accessibility purposes, but I can understand that might be infeasible and cause confusion in other areas. Perhaps this is just something users are going to have to get used to, but even so, this does mean that the distinction between modal and non-modal dialogs is important. I'd love to hear others' thoughts on this point.

[aleventhal]

On Windows (and perhaps ATK), I wonder if we could use the alert event in a similar way. To conform with the spec, this would have to be broadened to support elements with a role of dialog which don't have the modal state.

For MSAA, there's already EVENT_SYSTEM_DIALOGSTART (not sure that we'd need EVENT_SYSTEM_DIALOGEND), two events that have existed unused for a long time.
For ATK, there is no alert event AFAIK. For alerts, we notify of the SHOWING state change.

Related to the above, one concern I have is how most screen reader users will understand non-modal dialogs. My feeling is that when users hear a "dialog" get announced, they will think of a modal dialog and assume it has focus.

Interesting point. Certainly, "non-modal" or "modeless" is completely confusing. I think alert might be confusing too, because there a lot of use cases very far from that, e.g. a customer service chat window. I would have suggested maybe calling it a popup, but there is a different effort underway to standardize a popup attribute, and those have a "light dismiss" where they close if the user tabs away or clicks outside of it. Maybe we can still say "dialog" but need to add additional info, e.g. "dialog available, press F6 to navigate to it". Or something to that effect.

[mcking65]

@aleventhal @jcsteh
I've not been ignoring this. I've been drafting a gist explaining my concerns with modeless dialog landmark regions and an proposal for an alternate a course of action. I've worked on it some both of the last two weekends and will wrap it this weekend.

[mcking65]

@aleventhal @jcsteh

Sorry for the long delay. It has taken me many more hours to collect and attempt to clearly express my thinking on this topic than I anticipated.

It took me so long to respond because my answer is long. It will take time for people to read it. However, I believe it is what it needs to be ... this is a hugely impactful issue. The ramifications are truly enormous.

Please read the gist: An Accessibility Opportunity Hidden in Modeless Web Dialogs.

[cookiecrook]

To clarify, is "modeless" (used multiple times above) meant to mean "modal-less (aka non-modal)"? Are these being used interchangeably, or is there a distinction I've missed. "modal" and "non-modal" is clear. "mode-less" seems more ambiguous. Thanks for clarifying.

[scottaohara]

yes, @cookiecrook. modeless and non-modal mean the same thing.

[mcking65]

Is there a preference for one term or the other -- non-modal or modeless? Is one better than the other in spec language?

[aleventhal]

I grew up with modeless, but some of the standards folks didn't know what that meant, so I started saying non-modal.

[ggordon-vispero]

Broadly speaking, I like the idea of treating non-modal dialogs as something other than additional landmarks. Landmarks are great, but they don't imply any sort of hierarchy. To me, non-modal dialogs are a way of breaking an app into logical parts that a user can reason about and efficiently transition between. If I have a page open with three non-modal dialogs and each of those dialogs contains three or four landmarks, there's no quick way for me to identify that the page has several non-modal dialogs, nor is there a way for me to quickly move between them without first encountering a bunch of additional landmarks. I think that Matt's proposal offers an elegant solution to this.