SC 2.5.3 Label in Name - One Visible Text Label with Multiple Input Fields

[miheeyaa]

Hello,
I would like to request clarification on the scope of “visible label” in SC 2.5.3 Label in Name, as we are encountering different interpretations in real-world projects.

1. Summary of the Issue

In the following UI pattern:

• There is one visible text label (positioned visually like a label)
• There are two or more input fields associated with that text

…it is unclear how strictly “visible label” should be interpreted for SC 2.5.3, especially when applying a proximity-based or conservative definition.

We reviewed the Understanding section, but it does not explicitly address cases where one visible text applies to multiple interactive components.

• Identifying label text for components
  https://www.w3.org/WAI/WCAG22/Understanding/label-in-name.html#identifying-label-text-for-components
• This pattern also does not appear in the ACT Rule 2ee8b8 examples:
  https://www.w3.org/WAI/standards-guidelines/act/rules/2ee8b8/proposed/

2. Minimal Example

Example 1: “Enter Email Address”

One visible text:
Enter Email Address

Associated input components:

• Email ID text field
• Email domain text field
• Domain selection combobox

Example 2: “Phone Number”

One visible text:
Phone Number

Associated components:

• Country code combobox
• Phone number text field

3. Two Contradicting Interpretations in Practice

Interpretation A — “No visible label for each input”

• Placeholder text or default values are not visible labels.
• Because each input field does not have its own 1:1 visible label,
  these controls are not considered applicable to SC 2.5.3.

Interpretation B — “Single group label applies to all inputs”

• The left text (“Enter Email Address”, “Phone Number”) is treated as the visible label for all associated input fields.
• Therefore, the accessible name for each input should begin with the visible text.
  e.g.,
  “Enter Email Address ID”
  “Enter Email Address Domain”

4. Questions (Areas Requiring Clarification in the Standard)

Q1.

Should the “visible label” in SC 2.5.3 be interpreted as a concept that must be in a 1:1 relationship with each interactive element?
Or is it acceptable for a single visible text to cover multiple related input fields?

Q2.

When several input fields are grouped under one visible text label,
does each input’s accessible name need to start with that visible label to meet SC 2.5.3?

Or is it sufficient for each field to use its own descriptive name, such as:

• “Email ID”
• “Email Domain”

even if they do not begin with the shared visible text?

Q3.

Considering the intent of SC 2.5.3 (enabling speech-input users to activate elements using the visible text they see),
is there a recommended pattern or best practice for multi-field structures like these?

If helpful, I can also provide representative code samples.
Thank you very much for your guidance.

[TestPartners]

I don't see how this design pattern can ever meet all the relevant WCAG success criteria. In my view, every form control must have its own label. If there is a label for a group of form controls, it should be in a <legend> element in a <fieldset> that encloses the form controls. There is an example at
https://design-system.service.gov.uk/components/date-input/

[miheeyaa]

@TestPartners
Thank you for your feedback. I agree that this pattern could also create issues for SC 2.4.6 Headings and Labels. Ideally, each form control would have its own clear label or be placed inside a <fieldset> with a <legend>.

However, in this case I am trying to understand how SC 2.5.3 should be evaluated given the current UI structure, even though the structure itself may not be ideal.

This multi-field pattern (one visible text + multiple inputs) is unfortunately very common in Korean web services, and we must evaluate SC 2.5.3 as-is, because this project is required to meet WCAG Level A only, and we do not have the ability to restructure the form.

So the key question is:
When the UI already exists in this form, what does “visible label” mean in SC 2.5.3?

I understand your point about the need for individual labels, but I would like to clarify the following:

1. If the visible text is not considered a label for each control (Interpretation A),
   does SC 2.5.3 simply not apply to any of the fields?

2. If it is considered a group label (Interpretation B),
   does SC 2.5.3 require each control’s accessible name to begin with the shared visible text?

I would very much appreciate your thoughts—or perspectives from others—as to how SC 2.5.3 should be applied in these situations, even if the UI may violate other success criteria.

Thank you again. Your feedback is very helpful for keeping this discussion focused.

[TestPartners]

My view is that the form controls do not have labels, so SC 2.5.3 passes. However, SC 3.3.2 (Labels or Instructions) fails. SC 2.4.6 (Headings and Labels) also passes because it does not require that there are any labels.

If it is not possible to add labels above each form control, the only other option is to add floating labels inside them. I appreciate that this technique is controversial, but it is WCAG conformant when implemented correctly. Sometimes it is the only option when the design is constrained as it is in this case.

If the designers won't allow floating labels or labels above each form control, you need to tell them that the design cannot be made WCAG conformant. I have done this many times. Designers cannot expect you to take a bad design and magically make it accessible despite all the constraints they place on it.

[mbgower]

Further to @TestPartners comments, design considerations are often what is surfaced in questions surrounding 2.5.3.

I also agree that this example doesn't necessarily pose a Label in Name problem. If a user navigating by voice speaks any of the labels visible on the screen, they are likely to be moved to either the field they wish to be on, or one in close proximity to it. It is more likely a straight-ahead problem with absent labels.

It is not really clear why there are multiple inputs on Question category. Likely when that is addressed in design, it will be a lot easier to figure out how to label these better.

The email address inputs are unorthodox. If critical, I think one could use a group label and add programmatic labels in order to pass, but I don't see why a more conventional email input isn't used.

The phone number construct is not ideal but not that unusual, and can be addressed with a group label and a variant of that offered in the final example of https://www.w3.org/WAI/WCAG21/Understanding/labels-or-instructions

@miheeyaa If you have any further questions about this, please ask. Otherwise, feel free to close this issue!

[TestPartners]

The phone number construct is not that unusual, and can be addressed with a variant of that offered in in the final example of https://www.w3.org/WAI/WCAG21/Understanding/labels-or-instructions

In my view, this example is not conformant and should be removed. The WCAG definition of a label states "A label is presented to all users". This is not the case if the label is only presented using a "title" attribute.

[mraccess77]

• SC 3.3.2 allows for labels or instructions.
• There is not a requirement that a label or instructions can't be applied to a group of components -and not individually - WCAG 2.x has no proximity/location requirement for labels or instructions.
• The understanding docs for SC 3.3.2 states "U.S. telephone number format, the punctuation is not sufficient to label the fields. The single "Phone number" label also cannot label all three fields. To address this, the three fields are grouped in a fieldset with the legend "Phone number". Visual labels for the fields (beyond the punctuation) cannot be provided in the design, so invisible labels are provided with the "title" attribute to each of the three fields. The value of this attribute for the three fields are, respectively, "Area Code", "Exchange", and "Number". " https://www.w3.org/WAI/WCAG22/Understanding/labels-or-instructions.html