Update 3.3.2 Labels or Instructions Understanding Doc #4056
Conversation
Restore the need for accuracy/correctness to 3.3.2 Labels or Instructions
✅ Deploy Preview for wcag2 ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
| the task without undue confusion or navigation. | ||
| </p> | ||
|
|
||
| <p>This Success Criterion does not require that labels or instructions be correctly marked up, | ||
| identified, or associated with their respective controls - this aspect is covered separately by | ||
| <a href="info-and-relationships">1.3.1: Info and Relationships</a>. It is possible for content | ||
| to pass this Success Criterion (providing relevant labels and instructions) while failing | ||
| to pass this Success Criterion (providing relevant, accurate labels and instructions) while failing |
There was a problem hiding this comment.
is this not redundant? i can't think of a situation where a relevant label or instruction is not implicitly accurate?
| @@ -21,29 +21,29 @@ <h2>In brief</h2> | |||
| <section id="intent"> | |||
| <h2>Intent of Labels or Instructions</h2> | |||
|
|
|||
| <p>The intent of this Success Criterion is to have content authors present instructions | |||
| or labels that identify the controls in a form so that users know what input data | |||
| <p>The intent of this Success Criterion is to have content authors present accurate instructions | |||
There was a problem hiding this comment.
i understand your goal of making it clear that 3.3.2 should include making sure the labels are both present and meaningful - thus making 2.4.6 less meaningful - but i don't think just inserting the word 'accurate' (or its synonyms) whenever possible is necessary.
i'd recommend this sentence either insert "accurate" prior to 'instructions', or "clearly" / "concisely" prior to 'identify'.
The next sentence again adds "accurate and descriptive", and the sentence after that adds "accurately" (i don't find this particular addition necessary. we can cut this down.
| 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". | ||
| having a single, imprecise label "Name" (which would appear to leave the second text field unlabelled), | ||
| each field is given an explicit and accurate label - "Given Name" and "Family Name". This accurate labeling helps users understand where to input their first and last names, reducing confusion and ensuring correct data entry. |
There was a problem hiding this comment.
"and accurate" is an unnecessary add here, since the examples of "Given Name" and "Family Name" implicitly demonstrate they are more "accurate". Again, immediately following on with a sentence that also starts with reiterating the on the "accurate labeling" is enough.
| each field is given an explicit and accurate label - "Given Name" and "Family Name". This accurate labeling helps users understand where to input their first and last names, reducing confusion and ensuring correct data entry. | |
| each field is given an explicit label - "Given Name" and "Family Name". This more accurate labeling helps users understand the purpose of each field, decreasing the possibility of unnecessary mistakes. |
is it worth acknowledging the fact that the headings and labels mention of this example, as well as the mention of it on g131 say 'first name' and 'last name'?
should this update to match those? or those update to match this?
| <p>While this Success Criterion requires that controls and inputs have labels or instructions, whether or | ||
| not labels (if used) are sufficiently clear or descriptive is covered separately by | ||
| <a href="headings-and-labels">2.4.6: Headings and Labels</a>. | ||
| <p>While this Success Criterion requires that controls and inputs have labels or instructions, it is crucial that these labels or instructions are not only present but also accurate. The clarity and descriptiveness of labels are further addressed by <a href="headings-and-labels">2.4.6: Headings and Labels</a>. |
There was a problem hiding this comment.
Can one have an accurate (and descriptive) label, but also fail heading and labels? IMO, these additions make the 'label' part of headings and labels useless. I'm looking to understand how that's not the case.
Looking at the two docs together, there is no 'further addressing' in 2.4.6. Rather, 2.4.6 is rather concise/brief in the need for descriptive and sufficiently clear labels (and headings). 2.4.6's understanding doc seems to actually spend more time identifying what it doesn't cover than what it does :)
The benefits and examples already repeated content in this doc, but now this doc is more focused on the accuracy of the labels than the Headings and Labels doc is.
In other words, telling people accuracy of labels is further addressed in 2.4.6 is unfortunately false based on the current text of that document. Everything that document had to offer on label accuracy is essentially now here (and arguably more descriptive to boot).
So, I don't see how this update can be made if not flat out acknowledging that since accuracy of labels would be necessary for 3.3.2, then 2.4.6 is automatically met?
Maybe this can somehow be hair split into indicating that 3.3.2 label accuracy applies specifically to form fields, but more general instances of descriptive 'labels' fall under 2.4.6? I'm spit balling here to try and see how this PR can be accepted while not gutting half of the other SC's usefulness.
I just think some sort of clarification in 2.4.6 likely also needs to happen, otherwise this doc will say to go look at 2.4.6, and then that doc will barely repeat what's here, and say to go back to 3.3.2 for more info.
| users know what they are actually selecting. | ||
| Instructions or labels may also specify data formats for data entry fields, especially | ||
| Instructions or labels may also accurately specify data formats for data entry fields, especially |
There was a problem hiding this comment.
as mentioned in my previous comment, this seems an unnecessary add.
| Instructions or labels may also accurately specify data formats for data entry fields, especially | |
| Instructions or labels may also specify data formats for data entry fields, especially |
| if they are out of the customary formats or if there are specific rules for correct | ||
| input. Content authors may also choose to make such instructions available to users | ||
| only when the individual control has focus especially when instructions are long and | ||
| verbose. | ||
| </p> | ||
|
|
||
| <p>The intent of this Success Criterion is not to clutter the page with unnecessary information | ||
| but to provide important cues and instructions that will benefit people with disabilities. | ||
| but to provide accurate and essential cues and instructions that will benefit people with disabilities. |
There was a problem hiding this comment.
why 'essential' here when all other 'accurate and ' instances say 'descriptive'.
Maybe just say accurate? or just essential (i prefer this since it implies accuracy without having to use the word again)
|
Judging by the response to this PR, both here and in the ongoing discussion in #3984, I would ignore my attempts to pepper the document with references to "clarity" and "accuracy", and instead focus on my suggestion to provide some sort of acknowledgement/disclaimer that accuracy is implied. It doesn't even have to reference 2.4.6 at all and could just state: “While this Success Criterion requires that controls and inputs have labels or instructions, it is crucial that these labels or instructions are not only present but also accurate.” This wouldn’t enforce accuracy, it shouldn't impact the attempt to address the overlap with 2.4.6, but it would at least acknowledge and restate the goal and intent of 3.3.2. |
|
This PR (and related Issues) discussed on TF call today. Consensus on call is that this issue is best addressed by updating Understanding 2.4.6. @mbgower volunteered to review and propose something. |
|
Given that we are unlikely to get agreement on this PR, and Mike will look at an understanding doc update, I think we can close this PR. |
An attempt at restoring the need for accuracy/correctness to 3.3.2 Labels or Instructions, as discussed in #3984.
Inserts multiple references to accurate labels and instructions, expands upon one of the examples, and addresses the overlap with 2.4.6.
resolves #3984