Same example of proper label given for WCAG 2.4.6 and 3.3.2

[adamsamec]

Trying to figure out the clear difference between the WCAG Success criteria 2.4.6 and 3.3.2, I noticed they, in their respective "Understanding..." document, both use an example of assigning an appropriate label for given and family name form edit fields:

IN Understanding Success Criterion 2.4.6: Headings and Labels, there is the following example:

• A form asks for the name of the user. It consists of two input fields to ask for the first and last name. The first field is labeled First name, the second is labeled Last name.

In Understanding Success Criterion 3.3.2: Labels or Instructions, there is the following example:

• To enter their name, users are provided with two separate text fields. Rather than having a single label "Name" (which would appear to leave the second text field unlabelled), each field is given an explicit label - "Given Name" and "Family Name".

Now, let's assume there is a failing example where there are two edit fields next to each other preceded with the label "Name" so it is not clear in which field to put the given and to which the family name. So my question for this failing example is - which Success criterion between those two is actually failing? Or are failing both of them, and if so, then why?

Could the examples be more descriptive regarding why those examples are not failing?

[Vaibosnikov]

@adamsamec In my understanding, 2.4.6 suggests that headings and labels should be descriptive for the form fields as it would help the users to better understand what the form field is about while 3.3.2 suggests that form fields should have labels or instructions to let the users provide the expected input (such as texts, numbers, alphanumeric values) in the form field so that they won't make errors while providing the input.

Citing your problem statement here,

Now, let's assume there is a failing example where there are two edit fields next to each other preceded with the label "Name" so it is not clear in which field to put the given and to which the family name. So my question for this failing example is - which Success criterion between those two is actually failing? Or are failing both of them, and if so, then why?

IMO this would fail 2.4.6 as it is not clear to the users that what type of name does each edit field contain while 3.3.2 would get passed as input in the form of text is expected by the user.

[patrickhlauke]

3.3.2 demands that a form field has a label. one of these two fields has no label, so fails. 2.4.6 wants labels (where present) to be clear/descriptive, but that single label (for just the first input) isn't, as it doesn't sufficiently cover what that first input expects. so fails 2.4.6 too. IMO anywayOn 23 Sep 2024, at 08:03, Vaibhav Sharma ***@***.***> wrote: @adamsamec In my understanding, 2.4.6 suggests that headings and labels should be descriptive for the form fields as it would help the users to better understand what the form field is about while 3.3.2 suggests that form fields should have labels or instructions to let the users provide the expected input (such as texts, numbers, alphanumeric values) in the form field so that they won't make errors while providing the input. Citing your problem statement here, Now, let's assume there is a failing example where there are two edit fields next to each other preceded with the label "Name" so it is not clear in which field to put the given and to which the family name. So my question for this failing example is - which Success criterion between those two is actually failing? Or are failing both of them, and if so, then why? IMO this would fail 2.4.6 as it is not clear to the users that what type of name does each edit field contain while 3.3.2 would get passed as input in the form of text is expected by the user. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[adamsamec]

@patrickhlauke , you wrote "3.3.2 demands that a form field has a label. one of these two fields has no label, so fails". To my understanding, Both fields actually have a label, but the label is not programmatically associated with the second field, so it IMO fails 4.1.2 - Name, Role, Value instead of 3.3.2.

[Vaibosnikov]

@adamsamec WCAG 4.1.2 Name, Role, Value requires that controls should have name programmatically defined for them in HTML DOM, while WCAG 1.3.1 Info and Relationships points that the labels should be associated with their respective form field.

As you mentioned

Both fields actually have a label

This is actually a failure of WCAG 2.4.6 headings and labels, as those field do not sufficiently describe what type of data they should have. The user here might get impacted in terms of understanding that what name should be provided in each of the edit fields.

[adamsamec]

@Vaibosnikov ,

WCAG 4.1.2 Name, Role, Value requires that controls should have name programmatically defined for them in HTML DOM, while WCAG 1.3.1 Info and Relationships points that the labels should be associated with their respective form field.

Now I am even more confused :-). To my understanding, the association with the respected form field is achieved by programmatically defining the relationship in HTML DOM. So could you elaborate more the difference here? Do you think it fails 4.1.2?

The failure of WCAG 2.4.6 headings and labels in this example is clear to me. But I don't understand how it fails WCAG 3.3.2 as @patrickhlauke suggested.

[Vaibosnikov]

@adamsamec Normatively, WCAG 4.1.2 requires that your form field should have a name and role programmatically defined in the HTML DOM. Referring the sufficient technique H44, this is sufficient to meet WCAG 4.1.2 as well as WCAG 1.3.1 so if the edit fields are not programmatically associated with their respective labels, then this can be the case here where both of the success criteria fail not only one by not being associated with their labels.

[adamsamec]

Thanks, I think I got it now. WCAG 4.1.2 Name, Role, Value requires that name for a form field is programmatically set, but it could be done also using aria-label where the label would not be visible. Whereas WCAG 1.3.1 Info and Relationships requires that a visible label, if present, is programmatically associated with the respective form field.

@Vaibosnikov , you wrote that in the failing example I've given, WCAG 3.3.2 Labels or Instructions would pass. But why is then the following example in the Understanding document mentioned as an example passing the 3.3.2 success criterion? How does it demonstrate passing of 3.3.2?

To enter their name, users are provided with two separate text fields. Rather than having a single label "Name" (which would appear to leave the second text field unlabelled), each field is given an explicit label - "Given Name" and "Family Name.

[Vaibosnikov]

@adamsamec Sorry for the confusion here. Reiterating your problem statement - There are two edit fields having only one label (for first edit field only) and the second one does not have the label. I might think that I've oversighted your initial statement here 😅. Could you please provide the exact scenario.

What I am assuming now is that there are two edit field and only one label is there for the first edit field so normatively, for the second edit field 3.3.2 would fail as it needs to have a label so that users can expect what sort of input is required here without leaving the field empty.

[adamsamec]

I understand that my example fails 2.4.6 Headings and Labels, because the fields label is not clear and descriptive. But regarding other success criteria, I will provide more details about the assumed HTML implementation for my example. Let's consider three variants:

Variant A: the "Name" label is programmatically set only for the first field

• Here the second field has no programmatically set label, so is it correct that because of only that reason alone the second field fails both 1.3.1 Info and Relationships and 4.1.2 Name, Role and Value? Therefore in this case do these two criteria overlap?
• However is it correct that here 3.3.2 Labels or Instructions does not fail becaus the label "Name" is visually associated with both fields although ambiguous which name (given or family) it asks for?
• However, does the first field with the programmatically set label only fails 2.4.6 Headings and Labels and not 1.3.1 Info and Relationships, nor 4.1.2 Name, Role and Value?

Variant B: The "Name" label is programmaticallly set for neither of the two fields

• So is it correct that here both the fields fail both 1.3.1 Info and Relationships and 4.1.2 Name, Role and Value, only because of the missing programmatical relationship with the "Name" label? So also do these two criteria overlap because of this reason alone?
• However is it correct that here 3.3.2 Labels or Instructions does not fail becaus the label "Name" is visually associated with both fields although ambiguous which name (given or family) it asks for?

Variant C: The same "Name" label is programatically set for both fields

• Is it correct that here it fails only 2.4.6 Headings and Labels and not 1.3.1 Info and Relationships, nor 4.1.2 Name, Role and Value?
• However is it correct that here 3.3.2 Labels or Instructions does not fail becaus the label "Name" is visually associated with both fields although ambiguous which name (given or family) it asks for?