Repository navigation
Tweak 3.3.2 understanding benefits to align with intent - #1792
Conversation
…relevant remove the "clearly" aspects, and concentrate on the fact that each text field has a label.
having required fields explicitly noted as required in their label is a 2.4.6, not a 3.3.2, issue
|
While this is quite minimal...any chance to get this looked at/voted on/merged? @alastc |
|
One thought I had about this. If inputs are marked as required (or not), I think a legend could qualify as an "instruction". This consideration seems almost orthogonal to this SC -- and I think may be covered in another open issue -- but I wanted to flag this as an area still needing some attention and discussion. |
|
I agree with Mike that 3.3.2 covers instructions as well that may not be labels under SC 2.4.6 |
|
@mbgower how do you see that affecting this PR? |
I think the PR represents an improvement on guidance overall. But I think we should discuss form legends (particularly on required or optional fields) in light of this discussion at our Friday call, and ensure we have not exacerbated the 'problem', and that there is either an issue already captures this for future work, or we create one. For example, the guidance we've employed at IBM is that where there is use of a symbol, or where only some fields are marked, either as required or optional, there should be some instruction/legend. I'm not suggesting IBM's prescriptive guidance should be adopted by the WG; simply that IBM felt supported in making that guidance based on the wording of the relevant SC.s |
|
@mbgower you were going to locate an issue to do with required / non-required field indicators. Pat thought that was a headings & labels issue, but then it is an instruction. |
bruce-usab
left a comment
There was a problem hiding this comment.
I am not certain that an asterisk is universally recognized as meaning required (and so no further explanation needed), but I concur with proposed changes.
|
Opened #3622 |
|
Surely these changes go against the intent (if not the normative wording) of 3.3.2? If you remove any need for clarity or quality or accuracy, then what is the benefit of conforming to this SC? Picking up from #3795 (comment), you're effectively saying that anything goes, as long as it looks like a label or instruction. How does that help? At the very least, accuracy should be a given (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. |
Closes #1791, closes #1793, closes #1794
The main thrust of these changes are to remove any impression that the Labels or Instructions SC covers the quality of a label or instruction. The SC is merely about them existing. (Heading and Labels is the SC that covers how the label is described).