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.