Group Labels Do Not Guarantee… Uniquity?

There is a place where accessibility practitioners hang out and try to out-do each other with niche knowledge of nuance. While loitering in one, a question came up about text fields that have the same <label> text but are contained in groups with different group names.

This is a bad idea, of course. Do not give fields on a page the same accessible name no matter how they are grouped. Doing so could be failures of WCAG Success Criteria 2.5.3: Label in Name, 3.3.2: Labels or Instructions, and 4.1.2: Name, Role, Value (depending on how literally you read them). At the very least, this would be a terrible user experience.

But I was curious just how these fields might be exposed to screen reader users and whether screen readers might do some extra work on behalf of users. I wanted to know if screen readers would present distinct names to users via their own heuristics as a result of grouping structure.

Maybe relatedly, I have written about something similar (but different) in my post Uniquely Labeling Fields in a Table

Test Code

In my CodePen I have extra controls at the top and bottom of the page to provide a place from which to test jumping into the groups. But this is the minimum code you need to test the two grouping options. 

<fieldset>
  <legend>Piggy</legend>
  <label for="name1">Name:</label>
  <input type="text" id="name1">
  <label for="color1">Color:</label>
  <input type="text" id="color1">
</fieldset>

<div role="group" aria-labelledby="group2">
  <h3 id="group2">Doggo</h3>
  <label for="name2">Name:</label>
  <input type="text" id="name2">
  <label for="color2">Color:</label>
  <input type="text" id="color2">
</div>

See the Pen Testing Screen Reader Heuristics by Adrian Roselli (@aardrian) on CodePen.

Conclusions

Do not rely on a group label to provide a unique accessible name for text fields that otherwise have the same accessible name.

Even the heuristics built into screen readers to get around terrible developer habits will not save all your users.

If as a user you are stuck dealing with it in the wild then the best platform, browser, and screen reader combo to use is Windows 10 running IE11 with JAWS 2018. The worst combo is everything on mobile or anything with Narrator.

Testing Results

I tracked the tests I ran along with their outcomes. Feel free to waste your own time trying it with other combinations or versions.

2 Comments

Reply

Even the heuristics built into screen readers to get around terrible developer habits will not save all your users.

This seems too harsh when developers are using semantic groupings with accessible names as they’re intended. Only by exhaustively testing have you found that some screen reader/ browser combinations don’t do what they should some of the time.

Here you’re testing text fields grouped by fieldset but wouldn’t the same problems apply to fieldsets grouping radio buttons and checkboxes? For example, having a series of fieldsets with the question in the legend and the radio button labels as simply “Yes” and “No” seems reasonable; should every one repeat the question text (e.g. “Do you like bananas?” “Yes, I like bananas” “No, I do not like bananas”)?

Understanding Success Criterion 2.5.3: Label in Name doesn’t appear to address the uniqueness of field labels, only that the legend won’t be a part of the name calculation.

Developers trying to be aware of the issues will find differing guidance from different, good sources. In the WAI tutorial on grouping controls, the related fields example is a common use-case, shipping and billing address. There are separate shipping and billing fieldsets with legends but the visual field names are not unique. It notes that not every screen reader will read the legend with every form element and, to compensate, adds a visually hidden “Shipping” and “Billing” to only the first field in each fieldset, the rest have identical accessible names.. The page predates the addition of 2.5.3: Label in Name in WCAG 2.1 which this strategy violates because the visible part is not the first part; moving the visually hidden part to the end of the name would be awkward, at best.

The tutorial also alludes to a usability downside to making every field name unique; the duplicative text when a screen reader *does* read the fieldset legend. It doesn’t seem like an improvement to get rid of the legend and make every field label “Shipping Name,” “Shipping Address,” Shipping State,” etc. It might also make for a worse user experience when visually read.

Curtis Wilcox; . Permalink
In response to Curtis Wilcox. Reply

Only by exhaustively testing have you found that some screen reader/ browser combinations don’t do what they should some of the time.

Browser/SR combos are doing exactly what they should be doing. I was testing to see if a problematic pattern is being actively mitigated by SRs.

Here you’re testing text fields grouped by fieldset but wouldn’t the same problems apply to fieldsets grouping radio buttons and checkboxes?

Yes, but since that is an understood challenge (IMO) and was not the question that kicked this process off, I opted to skip it.

Understanding Success Criterion 2.5.3: Label in Name doesn’t appear to address the uniqueness of field labels, only that the legend won’t be a part of the name calculation.

You are correct on a strict reading, but I am also looking at it from the context of a voice-only user trying to name which field to be edited.

Otherwise, I agree with your comments. Naming every field uniquely can be a noisy affair for screen reader users. My caution here was that not doing so can have its own negative impact. As authors we need to be careful how we expose field names and about the assumptions we make for how easy or hard they may be to understand and how AT consumes them.

Leave a Comment or Response

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>