I did some more investigation and found that the radio buttons do already have `name` attributes. The `name` attribute is [added here](https://searchfox.org/mozilla-central/rev/d405168c4d3c0fb900a7354ae17bb34e939af996/browser/components/aboutwelcome/content-src/components/MultiSelect.jsx#111) for each radio button, provided it has a `group` property. The survey radio buttons have that property, [defined here](https://searchfox.org/mozilla-central/rev/d405168c4d3c0fb900a7354ae17bb34e939af996/browser/components/aboutwelcome/actors/AboutWelcomeChild.sys.mjs#527,534,541,548,555,626,633,640). I think that's just not enough to form a group for a11y tools. It's a bit confusing, because `name` is [what we use](https://searchfox.org/mozilla-central/rev/d405168c4d3c0fb900a7354ae17bb34e939af996/dom/html/HTMLInputElement.cpp#6366-6386) to ensure only 1 button per group is checked and can be tab focused, but it seems to have no bearing on the accessible structure, which is apparently based solely on the ARIA role of ancestors. This is unfortunate for our purposes because, to keep the radiogroup component generic, we don't want to add a `<legend>` element. Our original goal in creating the "radiogroup" component/template was that it should have purely radio buttons and/or checkboxes for children, because it's not specifically a "survey" component or a "question/answer" component. It's a reusable, generic "multi-select" component. We don't even really want to add `role="radiogroup"` because it's not strictly a radio group, as it can have checkboxes too or instead. But it doesn't cost us much to add `role="radiogroup"` dynamically when the message includes radio buttons, so I think we can do that. But yeah, ideally we'd keep the question outside of the multi-select component, which basically rules out fieldset + legend. An easy workaround I played around with is this: ```html <h1 class="title">Help improve Firefox</h1> <h2 id="question" class="subtitle">How satisfied are you with the Review Checker experience in Firefox?</h2> <div class="multi-select-container" role="radiogroup" aria-labelledby="question" > <!-- radio buttons... --> </div> ``` But I'm not sure if this is satisfactory, because it means both `#question` and `.multi-select-container` will have the same accessible label: "How satisfied are you with the Review Checker experience in Firefox?" So a screen reader might read that line twice (though thankfully the h2 is not focusable). I guess this is to some extent a problem either way. With fieldset + legend, the same thing could happen, but at least the legend is structurally inside the fieldset. So semantically that makes the most sense for this specific use case. It's just problematic for the Messaging System, because all our creations revolve around reusable components and generic templates. So we don't have the luxury of doing a bespoke solution for every individual UI application; we're able to work really fast and create a high volume of output because we use the most generic templates possible, allowing these kinds of things to deployed remotely without landing any code. That's why we're hesitant to add a "survey" component, since it's one more component we'll need to maintain. If we can get 95% of the results we want with a more basic "radio/checkbox group" component + the "subtitle" component, then that's always preferrable. And refactoring the radio/checkbox group component so that it's a fieldset with a visible legend inside, would make it less generic/reusable. I wouldn't rule it out entirely though, I just want to run the options by you Anna, and get a sense of whether you think we could solve this problem without changing where the subtitle/h2 is in the DOM hierarchy. If you're OK with the HTML example above, then that's highly preferrable for our purposes. But if that hierarchy is unacceptable then I suppose we will have no choice but to switch from using an h2 outside the radiogroup to a legend inside the radiogroup. I also tested out fieldset + legend, and it works similarly, the heading just ends up inside the radiogroup instead of before the radiogroup. In some ways fieldset actually seems worse, since its implicit role is `group`, not `radiogroup`? ```html <h1 class="title">Help improve Firefox</h1> <fieldset class="multi-select-container" aria-labelledby="question" > <legend id="question" class="subtitle">How satisfied are you with the Review Checker experience in Firefox?</legend> <!-- radio buttons... --> </fieldset> ``` In this example, I still added `aria-labelledby` to the fieldset, because without it, its label is `""`, and the question only shows up in the label of the legend, which is now the first child of the fieldset. That might be fine though - I don't know much about how these are supposed to behave.
Bug 1879655 Comment 6 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
I did some more investigation and found that the radio buttons do already have `name` attributes. The `name` attribute is [added here](https://searchfox.org/mozilla-central/rev/d405168c4d3c0fb900a7354ae17bb34e939af996/browser/components/aboutwelcome/content-src/components/MultiSelect.jsx#111) for each radio button, provided it has a `group` property. The survey radio buttons have that property, [defined here](https://searchfox.org/mozilla-central/rev/d405168c4d3c0fb900a7354ae17bb34e939af996/browser/components/aboutwelcome/actors/AboutWelcomeChild.sys.mjs#527,534,541,548,555,626,633,640). I think that's just not enough to form a group for a11y tools. It's a bit confusing, because `name` is [what we use](https://searchfox.org/mozilla-central/rev/d405168c4d3c0fb900a7354ae17bb34e939af996/dom/html/HTMLInputElement.cpp#6366-6386) to ensure only 1 button per group is checked and can be tab focused, but it seems to have no bearing on the accessible structure, which is apparently based solely on the ARIA role of ancestors. This is unfortunate for our purposes because, to keep the radiogroup component generic, we don't want to add a `<legend>` element. Our original goal in creating the "radiogroup" component/template was that it should have purely radio buttons and/or checkboxes for children, because it's not specifically a "survey" component or a "question/answer" component. It's a reusable, generic "multi-select" component. We don't even really want to add `role="radiogroup"` because it's not strictly a radio group, as it can have checkboxes too or instead. But it doesn't cost us much to add `role="radiogroup"` dynamically when the message includes radio buttons, so I think we can do that. But yeah, ideally we'd keep the question outside of the multi-select component, which basically rules out fieldset + legend. An easy workaround I played around with is this: ```html <h1 class="title">Help improve Firefox</h1> <h2 id="question" class="subtitle">How satisfied are you with the Review Checker experience in Firefox?</h2> <div class="multi-select-container" role="radiogroup" aria-labelledby="question" > <!-- radio buttons... --> </div> ``` But I'm not sure if this is satisfactory, because it means both `#question` and `.multi-select-container` will have the same accessible label: "How satisfied are you with the Review Checker experience in Firefox?" So a screen reader might read that line twice (though thankfully the h2 is not focusable). I guess this is to some extent a problem either way. With fieldset + legend, the same thing could happen, but at least the legend is structurally inside the fieldset. So semantically that makes the most sense for this specific use case. It's just problematic for the Messaging System, because all our creations revolve around reusable components and generic templates. So we don't have the luxury of doing a bespoke solution for every individual UI application; we're able to work really fast and create a high volume of output because we use the most generic templates possible, allowing these kinds of things to deployed remotely without landing any code. That's why we're hesitant to add a "survey" component, since it's one more component we'll need to maintain. If we can get 95% of the results we want with a more basic "radio/checkbox group" component + the "subtitle" component, which also works for other non-survey applications like the choices in about:welcome, then that's always preferrable. And refactoring the radio/checkbox group component so that it's a fieldset with a visible legend inside, would make it less generic/reusable. I wouldn't rule it out entirely though, I just want to run the options by you Anna, and get a sense of whether you think we could solve this problem without changing where the subtitle/h2 is in the DOM hierarchy. If you're OK with the HTML example above, then that's highly preferrable for our purposes. But if that hierarchy is unacceptable then I suppose we will have no choice but to switch from using an h2 outside the radiogroup to a legend inside the radiogroup. I also tested out fieldset + legend, and it works similarly, the heading just ends up inside the radiogroup instead of before the radiogroup. In some ways fieldset actually seems worse, since its implicit role is `group`, not `radiogroup`? ```html <h1 class="title">Help improve Firefox</h1> <fieldset class="multi-select-container" aria-labelledby="question" > <legend id="question" class="subtitle">How satisfied are you with the Review Checker experience in Firefox?</legend> <!-- radio buttons... --> </fieldset> ``` In this example, I still added `aria-labelledby` to the fieldset, because without it, its label is `""`, and the question only shows up in the label of the legend, which is now the first child of the fieldset. That might be fine though - I don't know much about how these are supposed to behave.