Question: controls within fieldset / group name redundancy

[scottaohara]

I'm curious to the decision behind appending the fieldset / checkbox / radio group's name to each of the descendant form element's accessible names. E.g., "Favorite Scientists" is the group name, and then each checkbox name repeats that at the end of their unique accessible name: "Archimedes Favorite scientists".

I don't see any specific callout in the explanation of each component to indicate why this redundancy was added, so it seems like a bug?

For instance, when I view the listing of form controls dialog, JAWS will return: "Favorite scientists Archimedes Favorites scientists checkbox..."

The first instance coming from the group name. The second instance from the repeat in the checkbox's accName.

[tlouisse]

Hi @scottaohara,

Thanks for checking out our product!

I’m afraid I’m the one to blame for this. It originated from the idea that individual fields children, when navigated by screenreader, should give as much as possible information about the context they are considered in. The idea is a bit similar to the example with [role=group] here: https://www.w3.org/WAI/tutorials/forms/grouping/#associating-related-controls-with-wai-aria. Here, the name of the fieldset is prefixed as sr-only/visuallyhidden content. In an a11y class I followed in the past I more or less learned that suffixing the name by default would give the user all the contextual info he needed, while first reading the most important info (hence a suffix instead of prefix). But doing this by default may have turned out to be ‘too aggressive’.

The goal - in the end - is to have the optimum between being as complete as possible and not providing redundant information. Reconsidering this, I think not providing the fieldset name as a suffix would have been the best default. I should have tested this more extensively after I implemented it. Usually @erikkroes spots these kind of things when he audits the total code base, but this was a relatively new addition and no audit has taken place yet I think.

When navigating all these w3c fieldset examples with VoiceOver, I see that the default behaviour of both fieldset and [role=group] (mentioning the group/fieldset label/legend after the first input once entering it, is enough.

I would be happy to change back the default to be just the child label :)

[scottaohara]

Thank you for the detailed response @tlouisse. I can follow the decision path from the WAI Tutorial where they repeat the group name with the first form control (as both would otherwise be "Name"), and if navigating by VoiceOver's rotor menu, these fields would be presented as "Name" if not for appending the "shipping" and "billing" group name, respectively.

It's a clever technique and in that example the two instances of redundancy (each name text field repeating the group's label/name) is rather benign as it only occurs twice. I would agree with your mentioning that this tactic, used on all descendant form controls is likely 'too aggressive', though I will also admit that there might be times, as shown when used purposefully with the WAI Tutorial, where providing the option to implement this behavior would be welcome.

For example, your "name" text fieldset example, where presently the text fields are announced as "First Name Name" and "Last Name Name". If the visible labels were merely "First" and "Last", thus providing those alone as the accessible names, this behavior would not be unreasonable at all. But again, it would be best to provide this as an option to developers to mitigate against the current behavior, and to also not inadvertently create awkward accessible names for common field labels. E.g., "Suffix" or "Middle Initial" are pretty straight forward in their meaning, when in the the context of filling out information about one's self. But if the fields were announced as "Suffix Name" and "Middle Initial Name" they likely would not "confuse" someone, but it may well give them pause to think "wait, what did I just hear? that's odd".

Anyway, long way to say "yes", I think reverting to more standard behavior, possibly with the option to allow developers to add this extra context, as needed, would be the right/expected way to go.

[tlouisse]

Completely makes sense to me. I think it was an attempt to make a smart default that didn't turn out that well. I think those smart defaults need to have at least a 99% 'success rate' and an easy way to opt out (which was definitely not the case here). Rather, we should provide good docs about how and when to use the "opt-in".

Thanks again for the feedback. If you have any more feedback about the other components as well: let us know :)

I will leave open this issue, so that we can revert the default behavior and ideally add some best practices documentation about the situations as described above.