Ambiguous labels and SC 2.5.3

[JAWS-test]

The page https://codepen.io/jaws-test/pen/JjMRwVe contains some labels that I think are difficult to evaluate in terms of 2.5.3, but are very common:

• Label for a radio button to activate an option and the same label for an input field to configure the option.
• One label for 2 fields
• One label for 3 fields that have a placeholder
• No label, but a button that serves as a label

In the following, I am only concerned with the correct answer to satisfy SC 2.5.3. I do not want to discuss the correct answers for SCs 1.3.1, 2.4.6, 3.3.2 or 4.1.2 here.

Label for a radio button to activate an option and the same label for an input field to configure the option.

What would be the correct name for the first radio button:

• Every (not meaningful but at first glance the visual label)
• Every . day (visible label without content of the input)
• Every 3. day (name according AccName specification)

And for the last radio button:

• Every month
• Every month on
• Every month on Monday

What would be the correct name for the first input field:

• Every
• Every . day
• Every 3. day

Can the name of the input be the same as the name of the radio button?

Or would 2.5.3 not be applicable because too complex?
Or should such forms be avoided because they cannot fulfill 2.5.3 and 1.3.1, 2.4.6, 3.3.2, 4.1.2 at the same time? The forms could be designed differently in order to fulfill 2.5.3 more easily, but the first example in particular then loses elegance and simplicity, see: https://codepen.io/jaws-test/pen/RwxGvvK

One label for 2 fields

What is correct name for the first input field

• First name (does not match with visible label)
• First and last name (is not meaningful)
• First and last name, here: First name (too long)

One label for 3 fields that have a placeholder

What is correct name for the last input field

• Date (not meaningful)
• dd (not meaningful, according to Understanding placeholder can serve as name)
• Date: dd (probably acceptable, contains both forms of the visible label)
• Date: day (maybe the best solution, but ignores the placeholder as name)

No label, but a button that serves as a label

What is correct name for the search field

• Search (the group name)
• e.g. CA 95383 (the placeholder)
• Search for zip code (the button)
• zip code (because "Search" is already in the group name)

[mbgower]

First, let's agree that all of those are not great designs, and there are better options!

It's always struck me as odd to advance a crappy design as an example of how the SC is problematic, when IMO the SC is providing the added benefit not only of ensuring things are labelled, but of helping people understand when a design is problematic. In other words, if I encountered any of these, my response would be to ask the authors to explain to me how they would meet 2.5.3, and when that proves difficult, to use that as a basis for changing the poor design.

So for the first one, there are better designs for a repeating pattern in most calendaring systems, and they generally solve this by letting the user choose the unit first and then adjust the period as a second step

Image 1: A screen shot of Outlook showing a Does not repeat dropdown that can be changed to Repeat daily, Repeat weekly, Repeat monthly, Repeat yearly and Custom.

Once that is answered, a Recurrence dialog appears:

Image 2: A recurrence dialog, providing Start, Repeat, Every and End fields.

At that point you only have one input with your 'Every _ unit' construct, which is a much easier thing to understand. So that's one way of improving the design.

There are even simpler redesigns that solve your other inputs

---

If we're going to tackle your examples, at the least, let's adjust the group label to be "Remind me every" so that the radio button options become less segmented. At that point in time, you should be able to put the label around the input value and following text so that the radio buttons read "3 days" and the input is labelled "days", etc. One assumes there is a starting value for these sub-components.

For your other examples, I think you should review https://www.w3.org/WAI/WCAG21/Understanding/labels-or-instructions.html (and https://www.w3.org/WAI/WCAG22/Understanding/headings-and-labels) and decide whether you think they meet that criterion before trying to tackle 2.5.3

[JAWS-test]

@mbgower My point was not to learn how to do it better (I provided examples for that myself), but to learn what would be a violation and what would not be a violation of SC 2.5.3 when evaluating existing pages with this design according to WCAG

[mbgower]

Okay, before proceeding with that exercise, can you clarify that you think these all pass Labels or Instructions and Headings and Labels?

[JAWS-test]

can you clarify that you think these all pass Labels or Instructions?

Yes, I think that 2.4.6 and 3.3.2 are fulfilled. But even if this is not the case, I would be interested to know for which AccName there is a violation of 2.5.3 and for which not

[mbgower]

Sorry for the delay getting an answer to you on this @JAWS-test.
This design is so problematic that I've returned to it a few times and just shaken my head, unsure how to respond without a lot of effort. I don't know how I or anyone trying to operate this interface by voice would attempt to interact with it! Remember, the whole point of this SC is to improve the ability for users who rely on speech for interaction to have a better experience. So, I re-emphasize my prior point that this design is difficult, almost impossible to use.

You've set a very clear request here:

In the following, I am only concerned with the correct answer to satisfy SC 2.5.3. I do not want to discuss the correct answers for SCs 1.3.1, 2.4.6, 3.3.2 or 4.1.2 here.

However, in my opinion, having looked at it again, I think this design fails Headings and labels. I think you would be hard-pressed to make the case that the labels describe input. The fact you're asking what the labels are seems to be self-evident that there's a problem.

So I think it is meaningless to carry out the exercise you've requested (and I spent quite a bit of time doing so in draft). This has already failed WCAG. Ultimately, if the labels make no sense, trying to match them programmatically is going to be fairly pointless. In prior comments in this thread, I've shown some ways the labels could be improved; and as a result the meeting of Label in Name becomes simpler.

If you want try to construct something that obviously passes Headings and Labels but poses problems for Label in Name, we can return to this.

[JAWS-test]

@mbgower SC 2.4.6 allows indirect labels from the visual context, e.g. a search button after the input field or - as in your screenshot 2 above - a value of a form field that serves as a label for the next field.

Then I'll ask specifically about your positive example (which also contains a complex form with ambiguous labels):

• what is the AccName of "Every ... day(s)"?
• what is the AccName of the two fields that are visually labeled "End"?

[mbgower]

@JAWS-test, I really feel like your issue and questions are a little orthogonal to Label in Name. Is the point you're trying to make that a poorly executed design can be challenging to 'resolve' for label in name?

2.4.6 allows indirect labels from the visual context, e.g. a search button after the input field

Many search buttons today have no visual text label at all. In regard to the button after the input you refer to, it is extremely rare for that icon to contain any text (they're usually a magnifying glass icon). So they are irrelevant to Label in Name. In most implementations of search I see that have any text, it is typically placeholder. In such situations, the placeholder text will likely be the best choice for Label in name, which is discussed in the Label in Name Understanding document.

Then I'll ask specifically about your positive example... a complex form with ambiguous labels

I don't understand what you mean by the "positive example". Can you please clarify?
But just to focus on the second part of your statement, if the label is ambiguous, then how does it pass 2.4.6? And if the label is ambiguous, why would you expect some 'correct' answer for how to do label in name? Ignoring the obvious redesign need inferred, you're either going to have to pick what you think is least ambiguous or do some user research to figure out what works better for speech recognition users.

[mbgower]

To let you see where my draft response was going before I backtracked and put in today's comments, I thought I'd just paste what I had written below. Ignoring the fact it ends mid-sentence, is this the kind of response you were looking for?

Here is the basic guidance I will be using for this exercise, taken from the Understanding document:

Conventionally the label for user interface components is the adjacent text string. The typical positioning for left to right languages is:

• immediately to the left of comboboxes, dropdown lists, text inputs, and other widgets (or in the absence of left-side labels, immediately above and aligned with the left edge of each input)
• immediately to the right of checkboxes and radio buttons
• inside buttons and tabs or immediately below icons serving as buttons
  The rationale for some of these conventions is explained in G162: Positioning labels to maximize predictability of relationships.
   

Remind me group

 
There are 6 inputs in the "Remind me section" of the form, three radio buttons, each with a child input. The inputs bisect the text that is to the right of the inputs, like this: "Every [input]. day". The first two are text/numeric inputs for day and week. The last is a select which I assume has the days of the week as its options, and is preceded by the text "Every month on"

^ screen shot of Remind me section inputs, described in preceding paragraph
 

What would be the correct name for the first radio button:

• Every (not meaningful but at first glance the visual label)
• Every . day (visible label without content of the input)
• Every 3. day (name according AccName specification)

As mentioned, the design's bisection of the label in combination with child input is going to make a lot of work for trying to "fix" (there is no other word for it) the design. One cannot go with the usual text positioning for deciding on the label because... Well, they're a jumbled mess.
I'll mention that the design is likely going to be very confusing for screen reader interaction. I'm going to attempt to put in guidance here that can hopefully help both user groups.

To improve context, and to have the best chance of matching speech usage, IMO, the best choice is close to your third option but excludes the period: "Every 3 day". As noted in the Understanding document, punctuation is optional, and here the period is nonsensical.
 
I realize we are discussing speech interaction here, but it helps to think through the screen reader experience too. With this approach, a screen reader user would to tab into the "Remind me" radio group and hear something like "Every 3 day radio button, 1 of 3". Arrowing down will announce something like: "Every week, 2 of 3" and "Every month on Monday, 3 of 3". That's about the best one could hope for from that perspective without changing the design at all. One thing it has going for it is that any likely string the user chose to speak to choose the radio buttons is part of its name. So odds are they will be moved there or that it will be one of the choices refined by the AT (such as numbering the possible choices).

That said, I think all three of your choices are viable choices given the horrid design. I don't think one could argue conclusively that any of them should be a failure, given the text provided to the user (assuming they match an equally poor programmatic label).

I repeat: there are ridiculously simple ways to make this design better. I mention a few in previous comments. I'd be pushing back in my assessment.
 

What would be the correct name for the first input field:

• Every
• Every . day
• Every 3. day

So it helps to think how the interaction for these inputs should be. Ideally, the input should be a child of the input, so that it only takes focus when its parent is selected. That means the others are going to be disabled, so they will not be directly navigable or selectable until the parent radio button is selected. Even if they were not implemented as children, in most interactions, a speech input user is going to navigate to the radio button and just say "Press tab" to move there.
With that in mind, getting this label 'right' isn't so critical since its name is unlikely to impede interaction. If we're on the first one, probably the best one is just "day" with a numeric input. The screen reader user already has the context of what radio button they were on (assuming you go with my recommendation), but that should help. Of the three choices you say, I think the third is not a great choice since it includes the value of the input I'm trying to interact with. In the parent, it made sense to include the child's value since it concatenated into a meaningful string. The same can't be said here. That's not how a speech input user operates, and it would also be potentially confusing for a screen reader user...

[JAWS-test]

I am not concerned with how to make the design of these forms better. I am not a web designer. I am an accessibility tester and I have to decide every day whether or not there is a violation of SC 2.5.3 in the pages and applications I test. Therefore, I want to know if the complex form designs that are common (e.g. Outlook recurring appointment) comply with 2.5.3 or not, or how the form fields need to be labeled programmatically to comply with 2.5.3. The answer could be:

• 2.5.3 does not apply to the forms because they are too complex and with voice input they have to be operated differently (you wrote: "With that in mind, getting this label 'right' isn't so critical since its name is unlikely to impede interaction")
• 2.5.3 does apply and because they are too complex they need to be rebuilt and simplified (you wrote: "there are better designs")
• 2.5.3 applies, but there is a meaningful AccName that matches the visual representation (you wrote: "That said, I think all three of your choices are viable choices given the horrid design. I don't think one could argue conclusively that any of them should be a failure, given the text provided to the user").

So: I realize that there are better designs, and I also realize that voice input users have other options for operation and navigation with poor designs: I just want to know: When do I have to say as a tester of such a form: you have violated 2.5.3?

[JAWS-test]

I don't understand what you mean by the "positive example". Can you please clarify?

Your 2nd screenshot in #2277 (comment)

[bruce-usab]

FWIW, using the Windows desktop client, complex fields of kind like Outlook recurring appointment are compatible with Assistive Technology (including both screen reading and voice recognition).

[mbgower]

I am not concerned with how to make the design of these forms better.

I'm not quite sure why you responded to my last comment like that. I thought I was answering your question. I assessed the 3 scenarios you offered, said what I thought was best, and what I thought was borderline but maybe, contextually okay.

I just want to know: When do I have to say as a tester of such a form: you have violated 2.5.3?

Maybe this comes down to a testing philosophy, @JAWS-test?
If I came across the example you started with, I would fail it against 2.4.6. I'd make a note in 2.5.3 (and probably 1.3.1) that these labels will need to be reassessed after the failure of 2.4.6 is remediated and the labels are less ambiguous. Depending on who the team is, and the level of feedback I provide in this environment, I may give some of the information in this discussion to help them in the remediation. I'd definitely anticipate some discussions.
I have done this exact thing with pagination in a table, which can have similar conflated control-label combinations.

Depending on the team and state of the application, they may or may not want to send this back to design. They may not be allowed. In that case, I'd be assessing how these labels are programmatically constructed and see if how it's been done gives some adequate match between the visible text nearby and what is set as the label. (Obviously at some point one is going to have to check the programmatic values, because that's part of 2.5.3's criteria.) Depending on the outcome of that exploration, I may change my 2.4.6 to a caution and set 2.5.3 as a caution as well, fail them both, or leave it with my original assessment.

If I'm not satisfied, there may be ways of tweaking the labels programmatically without changing the UI to get to something I think can be considered borderline pass or put down to a lower severity. So that could also be a recommendation for the devs.

So, key message here is: when the design isn't clear, I don't think you can assess Label in Name in isolation. You're going to have to assess at least three SCs, IMO (1.3.1, 2.4.6, 2.5.3 and often 4.1.2). When the design is clear, 2.4.6 comes out of the equation.

If you have a look at the three bullets you provided in your prior comment, I think you can equate my comments with the last two.

2.5.3 does apply and because they are too complex they need to be rebuilt and simplified (you wrote: "there are better designs")
2.5.3 applies, but there is a meaningful AccName that matches the visual representation (you wrote: "That said, I think all three of your choices are viable choices given the horrid design. I don't think one could argue conclusively that any of them should be a failure, given the text provided to the user").

---

In regard to:

Therefore, I want to know if the complex form designs that are common (e.g. Outlook recurring appointment) comply with 2.5.3 or not...

I was the one who mentioned Outlook in the thread and how its recurring events are constructed to make them more accessible and make it easier to assess Label in Name. Both the screen shots I used and the Outlook one you provided have no obvious potential problems associating meaningful labels with controls, and hence with Label in Name. I haven't bothered inspecting Outlook under the covers. Is there something you feel is implemented in such a way in Outlook it makes it difficult to assess 2.5.3?

[mbgower]

I just had a thought. I wonder if this works as a Draft response:

The primary purpose of Label in Name is to make sure this kind of thing doesn't happen:

<label>Search</label>
<input aria-label="Find whatever you want">

In the scenario you have provided, we've thrashed around trying to assess wtf the label is. But at its more simple level, the job of a tester is to see if what is programmatically the label matches what is visually there.
So maybe a process that would work for you is to:

• assess 2.4.6 Headings and Labels ; if you do think it passes, we can just agree to disagree on that
• assess the programmatic label to ensure 1.3.1 is working
• see if you think the text chosen for the label is physically near the input (any of the three thing you listed would be 'okay' if they match the programmatic label)

Does that get you to a clearer approach?

[JAWS-test]

@mbgower I think part of the misunderstanding comes from the fact that you think my examples violate 2.4.6, but I don't think my examples violate 2.4.6. Visually, the purpose of the form elements is clear because of the labels before and after them. Thus, I don't need to bother with 2.4.6 in the examples. Even with 1.3.1 everything can be correct: For "First and last name", the first field can be labeled "First name" per aria-label. The problem with 2.5.3 would be that the visible label "First and last name" is not part of the AccName "First name". Or is it expected here that the user separates that composite label into "First name" and "Last name". I don't mind and don't think this is too much to ask: only we should agree that "First name" is then not a violation of 2.5.3 - and document this in the Understanding.