Restore the need for accuracy/correctness to 3.3.2 Labels or Instructions #3984
Description
A recently published update to the Understanding document for 3.3.2 Labels or Instructions has made changes that effectively render the success criterion pointless.
In an attempt to disambiguate the slight overlap between 3.3.2 Labels or Instructions and 2.4.6 Headings and Labels, #1792 removed several references to the need for "clear and unambiguous" labels and instructions. The justification was that 2.4.6 concerns the quality of headings and labels, whereas 3.3.2 concerns the mere presence of labels or instructions (regardless of how good/comprehensive/accurate they are). This, I feel, was a misstep.
As others and I commented elsewhere, these changes go against the intent (if not the normative wording) of 3.3.2.
The normative text - "Labels or instructions are provided when content requires user input" - is unhelpfully terse.
However, the stated goal that "Users know what information to enter" and the intent "to have content authors present instructions or labels that identify the controls in a form so that users know what input data is expected" is more indicative of the intended purpose of 3.3.2.
By removing any need for clarity or quality or accuracy in 3.3.2, then what is the benefit of conforming to this SC?
(Also, if any requirement for clarity or descriptiveness is punted squarely to 2.4.6, why list G131: Providing descriptive labels as a sufficient technique?)
Picking up from #3795 (comment), 3.3.2 now effectively says that anything goes, as long as it looks like a label or instruction. How does that help users?
Without any requirement for accuracy or correctness...
- a nonsense label would pass 3.3.2:
<label for="tel">XWPSWTLNMZ</label> - an incorrect label would pass 3.3.2:
<label for="tel">Name</label> - an ambiguous label would pass 3.3.2:
<label for="consent">I agree</label>
Now, you could argue that these examples impact everyone and therefore can be considered "bad UX" and beyond the scope of WCAG. But if that's the case, why have this success criterion at all? Who does the mere provision of labels or instructions actually benefit?
It would be like saying that 1.1.1 Non-text Content should only be about the presence of a text alternative, not about whether the text alternative accurately describes the content. Admittedly, 1.1.1 has the additional clause of "a text alternative that serves the equivalent purpose" and 1.1.1 also hasn't been split over two closely related success criteria, but that's where we are. In my opinion, 3.3.2 would greatly benefit from a similar qualifying clause, if not in the normative text then in the Understanding document.
At the very least, accuracy should be an explicit expectation of 3.3.2 (in that, the label or instruction must identify/explain what the control does). Whether it does that clearly or sufficiently descriptively is then a matter for 2.4.6 (although I accept that an accurate/correct label will likely be sufficiently descriptive for 2.4.6 in most cases).
In terms of specific actions, I wouldn't necessarily reverse the changes in #1792, but instead make an explicit expectation of accuracy. So, for example:
- What to do: Provide labels or instructions for inputs [that accurately describes what data is expected].
- "The intent of this Success Criterion is to have content authors present instructions or labels that [accurately] identify the controls in a form so that users know what input data is expected."
- "While this Success Criterion requires that controls and inputs have [accurate] labels or instructions, whether or not labels (if used) are sufficiently clear or descriptive is covered separately by 2.4.6: Headings and Labels."
And perhaps even an additional sentence to emphasize the need for accuracy:
- "Although WCAG 3.3.2 focuses primarily on ensuring that labels or instructions are provided, it is still essential that these labels or instructions are accurate."