Remove name required from alertdialog, dialog, form, grid, radiogroup, table

[scottaohara]

closes #2180
related to recent question: #2296
related to #1764

This PR removes requiring names for alertdialog, dialog, form, grid, radiogroup and table roles and replaces the author MUST with an author SHOULD. (for grid/table there was no author MUST naming paragraph, so the author SHOULD paragraph was added to these roles).

With this change there will likely be necessary updates to related APG/MDN docs.

• Related APG Issue/PR:
• MDN Issue/PR:

---

Preview | Diff

[netlify]

✅ Deploy Preview for wai-aria ready!

Name	Link
🔨 Latest commit	c5b1911
🔍 Latest deploy log	https://app.netlify.com/sites/wai-aria/deploys/67aa4f8f287d0f0008e97dde
😎 Deploy Preview	https://deploy-preview-2297--wai-aria.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[giacomo-petri]

Hi group,

I prefer to keep things simple, and I really like this change. However, I strongly believe there's a significant difference between:

• alertdialog
• dialog (with aria-modal="true")

and

• form
• grid
• radiogroup
• table

I understand that repeating the main heading of a modal in its accessible name can sometimes feel redundant. However, if focus moves to the modal and the screen reader only announces it as a "modal dialog", users are forced to navigate inside just to understand its purpose, which isn't efficient either. In this case, I'd prefer some redundancy over making users enter a modal they may not even need.

That said, I can live with either approach, but I want to note that I do think expectations for the roles above differ.

[smockle]

…if focus moves to the modal and the screen reader only announces it as a "modal dialog", users are forced to navigate inside just to understand its purpose, which isn't efficient…

@giacomo-petri: How common is it to focus the modal itself? Is that something web authors should be doing?

At GitHub, we typically move focus to an interactive element inside a modal dialog (e.g. a close button). ARIA APG’s Modal Dialog Example and Date Picker Dialog Example do this too—in the former example, the “Street” input is focused; in the latter, a <td> with tabindex=0 representing the current date.

❧

To speed things along, should we split this PR? One PR could remove ‘name required’ from form, grid, radiogroup, and table; the other could remove ‘name required’ from alertdialog and dialog (with aria-modal="true"). That’d let us address the confusion in #2431 right away, while giving us time to discuss the dialog case further.

[giacomo-petri]

If an alert dialog requires a choice (e.g., "Accept" or "Decline") and cannot be dismissed without selection, immediately shifting focus to one of the options without providing context, I believe it creates a poor user experience.

Similarly, opening a dialog and moving focus directly to the close button is also ineffective. Ideally, the topic or purpose of the dialog should be announced first before presenting the option to close it (IMO).

So if the dialog has a meaningful acc name and the focus is moved on it, the role will be announced altogether with the label, providing some context.

[scottaohara]

fwiw, @giacomo-petri and i spoke today and we agree that i many cases it would be beneficial for dialogs to have accessible names. but, the point of this update is not to say that dialogs wouldn't benefit form accnames, but to acknowledge the fact that not every dialog needs an accname - and thus why an author MUST is too strict, and it out of alignment with HTML not requiring dialogs to be named.

all that said, if there is any further editorial one would like to see added to this PR to further note that accNames are recommended but not required for dialogs, please provide a suggestion of such text, or we should make a separate PR for that. But i would very much like to not regress on the previous decision and split this PR apart.

[smockle]

Thanks @scottaohara; that makes sense. 👍

Incidentally, reviewing the 2024-05-23 minutes, you said almost the same thing then:

scott: …I'm not arguing that there aren't cases where things do need names, the issue is that this is a pass/fail boolean right now, and we're saying that these always need a name and that's not true
scott: just want to be absolutely clear that I'm not saying dialogs don't require names, that would be a misunderstanding. I still agree that in most cases, it would be good, and people should provide names to these things. I think it's an overreach to say they're always required