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

[Wildebrew]

I hate to introduce a complication, but I think radiogroup is a very different role from the rest.
Radiogroup represents a group of form controls. Radio buttons trigger screen readers to switch into forms/application mode, which makes reading static content complicated (you have to switch in and out of browse mode), not to mention that usres expect to be able to navigate forms with the tab key.

Given the tendency of using standard labels for radio buttons and relying on the group label to differentiate them, it would significantly complicate the screen reader user experience not to have an accessible name for each group.

Imagine a standard survey with 8 or 9 questions on the same page.
The questions will touch on various aspects of a recent user experience.
The radio buttons in each group have the same labels, e.g. "yes" and "no", or "agree" "somewhat agree" and "disagree".
Without the group label you have no idea, as a screen reader user, what you are responding to.
Yes, you could force the screen reader out of application/forms mode and then navigate up past the first radio button to find the static content that represents the question, hopefully the question is coded as a heading to make this process easier. But switching interaction modes for a screen reader is not exactly a super simple trick, especially with auto forms mode on (which is the default behavior of most screen readers).

In my experience, not having a group label on such a page is likely to increase the time required to answer a set of 5 questions with standard group labels by a factor of 4 or more. I admit that I do not have official study statistics to back this up but I've used a screen reader for over 30 years myself, trained dozens of people on how to use a screen reader, and even translated NVDA (into Icelandic).

To sum up, given radiogroup's strong association with forms I recommend to remove it from this list and continuing to require an accessible name for it.

In fact I would go so far as to argue that the group role should be upgraded to require an accessible name as well, since it is inevitably used for grouping form controls, including radio buttons or text inputs that trigger screen readers to switch to application/forms mode and users navigating those with the tab key instead of carefully perusing the content.

Keep in mind that the <fieldset> element maps to the group role, and if you are going to group radio buttons with HTML, that is the element you use.

[stevefaulkner]

yeah i agree with @Wildebrew if a radiogroup role is used to identify a set of radio buttons it must have an accname, otherwise the group label of the set of controls will not understood.

please can someone provide the use case for radiogroup with no label? it serves no one

[smockle]

Here’s an example @scottaohara provided in #427 (comment):

<div role=radiogroup>
  <label><input type=radio name=f> I think radiogroups should always have a name</label>
  <label><input type=radio name=f> I do not think radiogroups should always have a name</label>
</div>

per the current spec, it would be required to add a name. but the names of the radio groups make it pretty clear what the intent of the group is asking one to decide.

[Wildebrew]

That's not how the vast majority of radio buttons are coded. The whole idea of grouping controls is to remove repeated text and make the experience easier to understand. If I saw that example in the wild I would make an accessibility usability recommendation to change it to ``` <div role="radiogroup" aria-labelledby="q2"> <h2 id="q2">Do you think radiogroup should have an accessible name?</h2> <label> <input type="radio" name="q22"> <span>yes</span></label> <label> <input type="radio" name="q22"> <span>No</span></label> </div> ``` Advantages: * You can skim the questions by navigating by headings before you start * It's much easier to understand with a screen reader * For mobile devices, you save screen space by having shorter labels (verbose labels are tiresome and confusing for a screen reader user, especially long labels with repeated text)

[stevefaulkner]

@smockle @scottaohara What purpose does the role="radiogroup" role serve in this instance? 

Who does its semantics serve? 

What does it impart that its absence wouldn't?

radiogroup becomes group in the acctree (on windows). Without an accesssible name both the group and radiogroup role are ignored by screen readers as I recall.

a few test cases

<div role=radiogroup>
  
<label><input type=radio name=f> I think radiogroups should always have a name</label>
  
<label><input type=radio name=f> I do not think radiogroups should always have a name</label>

</div>

[giacomo-petri]

This mirrors the discussion I had with Scott, where we agreed that while users often benefit from the accessible name in these roles, perhaps even the majority of the time, there are cases where it's unnecessary or redundant, making a strict "MUST" requirement too rigid.

For example, I've seen many quizzes where each page contains a single question as an h1, followed by answer choices wrapped in a <fieldset> tag. In such cases, assigning an accessible name to the radio group isn't required, as it would simply duplicate the <h1>. Here we're not debating whether it's a must, a best practice, a nice to have, or not needed at all; we're just pointing out that it's not always a strict requirement.

Regarding the question,

Who does its semantics serve?

we're not saying an accessible name shouldn't be set, just that it is not always necessary. In HTML, a <fieldset> can exist without a <legend>, right? We're aiming to clarify that while setting an accessible name is generally recommended, it's not always mandatory.

[stevefaulkner]

@giacomo-petri 

What I am saying is there is no scenario, that has been offered so far, that shows when <div role="radiogroup"> without an accessible name has any benefit. Would appreciate use cases. 

In regards to <fieldset> it is similar, but not the same as it has a default visual semantic (border), there is no wilful addition of a role annotation specifically for accessibility, to convey a semantic meaning.