-
Notifications
You must be signed in to change notification settings - Fork 283
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Question: controls within fieldset / group name redundancy #1576
Comments
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 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. 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 :) |
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. |
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). 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. |
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.
The text was updated successfully, but these errors were encountered: