Questions about role=dialog vs <dialog>

[Malvoz]

• In clarify that modal requires an accessible name #1180 the requirement of an accessible name for dialogs was introduced. A hard requirement for an accessible name makes it harder to advocate for role="dialog" usage where it otherwise would make sense, in cases where it's not easy to ensure an accessible name can be provided. What does it mean for <dialog>s without e.g. a heading element or aria-label? Should those fail HTML validation?
• In HTML, <dialog> can be closed (at least in Chrome) using the Esc key, but there's no mention of that in the role's description. Should there be?

[scottaohara]

What does it mean for s without e.g. a heading element or aria-label? Should those fail HTML validation?

no. HTML and ARIA are different specs with different requirements. Similarly, a role=table requires an accessible name from author. there is no requirement for such with <table> in the HTML spec, and it does not fail HTML validation if it does not have an accessible name.

That said, they should have accessible names, and to be in conformance with the ARIA spec names are required. But again, HTML and ARIA have different requirements for their usage.

Regarding your second question, the ARIA spec doesn't indicate any keys which should/need to be supported for roles. e.g., role=button doesn't say anything about space or enter key.

That sort of information can be found in ARIA Authoring Practices, where you'll see that Escape is listed in the Keyboard Support table, indicating the key closes the dialog.

[Malvoz]

they should have accessible names, and to be in conformance with the ARIA spec names are required. But again, HTML and ARIA have different requirements for their usage.

So in cases where it would be thought to be appropriate to use (non-modal) dialogs but where an accessible name cannot be guaranteed for each dialog we should not use role="dialog", but instead <dialog>, which is implicitly role="dialog". That's a bit awkward to reason about, but I understand that the specs have different requirements. And <dialog> is harder to convince people to use since they might be required to polyfill it.

Or perhaps it means that if an accessible name cannot be guaranteed then dialog is not appropriate at all.

ARIA spec doesn't indicate any keys which should/need to be supported for roles.

As such authors may not consider handling key presses to close dialogs when reading up on the role, which might end up being confusing to users as to why some dialogs (<dialog>) can be closed using Esc but other dialogs ( role="dialog") cannot.

In my uneducated opinion (and not considering that the spec traditionally does not mention keyboard interactions) I'd think there should be a SHOULD for keyboard interactions and/or a link to the WAI-ARIA Authoring Practice's recommended keyboard interactions for dialogs.

[jnurthen]

In my uneducated opinion (and not considering that the spec traditionally does not mention keyboard interactions) I'd think there should be a SHOULD for keyboard interactions and/or a link to the WAI-ARIA Authoring Practice's recommended keyboard interactions for dialogs.

#723 covers this

[jnurthen]

@Malvoz Can you provide any examples of such dialogs where an accessible name couldn't be added?

I don't believe I have ever come across a scenario where an accessible name would not improve the dialog. For an example where there is no visible name, the date picker dialog at https://w3c.github.io/aria-practices/examples/dialog-modal/datepicker-dialog.html has an aria-label of "Choose Date" as there is no visible dialog title.

[Malvoz]

I agree that an accessible name would always improve a dialog, but I'm not certain that it is always needed. The MDN example does not provide an accessible name for the <dialog>.

It's not that it couldn't technically be provided but more a question of do authors care to provide it in a re-usable component. OTOH the content may be dynamic and it's impossible to derive an accessible name from the content that populates a dialog (e.g. iframe).

The following component may be a case where dialogs should not be used (I'd greatly value your opinion on this); in this map (source) press any of the markers to expand a popup/dialog. Would it be appropriate to give that container a role of dialog? We've ensured that all of the markers have an accessible name, so the dialog/popup could derive an accessible name from that. But my intention is to file an upstream issue to the Leaflet JS library (which is the source for the popup's structure) since that container element is a plain <div> which I think can be improved, but they can't ensure all of their users provide all popups/"dialogs" (or indirectly from markers) with an accessible name.

Edit: I'm also considering other roles such as group for that component. But it's besides the point of this issue whether that particular component is suitable for role="dialog" or something else.

[scottaohara]

per the provided example, i could see that as a non-modal dialog.

i don't see why it couldn't be given the name of "location info" or the name of the actual location (as it appears when hovering/focusing the location marker), or something similar.

Even if you decide this component wasn't suitable for a dialog, and chose the group role as mentioned, you would still need to give it a name so that the group role would be consistently exposed. similar if you chose to use region. note: i see that group isn't presently marked as requiring an accessible name. this seems an oversight.

Stepping back from this specific example to whether dialogs need to require a name... while I generally agree with James that I think naming a dialog will be helpful - especially if there is no visible heading/label for the dialog's content (which can then pretty easily be referenced for its name if such a visible indicator were to exist), the following statement does not sit well with me:

Or perhaps it means that if an accessible name cannot be guaranteed then dialog is not appropriate at all.

if there are other people out there that are thinking "if i can't give a dialog a name, then i shouldn't use a dialog", then this requirement troubles me, as I think this should not be a blocker for someone looking to implement the correct role, but cannot guarantee, whether that's an actual difficult task or not, it to have a name.

[Malvoz]

i don't see why it couldn't be given the name of "location info" or the name of the actual location (as it appears when hovering/focusing the location marker), or something similar.

In our case (the Web Map Custom Element that attempts to polyfill MapML) it can be. But that "location info" on hover is not a default behavior of markers in the underlying library and markers (or other points of interest) are generally not labelled by developers. And no advice is given from these map libraries for developers to label them (and uniquely so), so deriving a name from something where developers generally don't care to (or are aware that they should) label that something is going to be hard.

if there are other people out there that are thinking "if i can't give a dialog a name, then i shouldn't use a dialog", then this requirement troubles me, as I think this should not be a blocker for someone looking to implement the correct role, but cannot guarantee, whether that's an actual difficult task or not, it to have a name.

I was indeed hesitant due to the new requirement about proposing to the library that they give the container semantics in the form of role="dialog" (aria-modal="false") by default. But I take it it's fine, even though developers may not give the dialogs an accessible name. In worst case scenario I suppose it's not going to be less accessible than a <div> anyways, so no harm done.

[scottaohara]

In worst case scenario I suppose it's not going to be less accessible than a <div> anyways, so no harm done.

exactly. From the picture you paint, it already sounds like an uphill battle of getting developers to markup the content correctly and with accessibility considerations. Might as well aim to get some of the parts of the UI marked up well, than nothing at all :)

[pkra]

Closing this as an answered question -- feel free to reopen.