-
Notifications
You must be signed in to change notification settings - Fork 281
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
3.3.2 and Required Fields #3553
Comments
Part II |
It's formulated like this because when having only required fields, you can also state that information up front as an instruction, satisfying the SC without the need to add additional required instructions to every single label. When you have mixed fields, marking the specific fields as required is useful (but it could still be solved in different manners as well) |
i'll mention, as an aside, that wcag.com is not an authoritative source of information, but something a particular company/vendor of accessibility services has set up (rather cheekily, in my opinion, and they're not really up-front about it) and yes, it all depends on context. if a form doesn't specify anything about whether or not a field is optional, the base assumption is that all fields are required, and it arguably doesn't need any explicit mention. for instance, a username/password login form ... of course both are required, and it would be patronisingly pointless to say that this needs to be spelled out to users (either on a per-field label basis, or even at the top of the form) |
IMO, it is a misreading of this SC to extroplate that the normative wording is only referring to inputs that are "required."
I agree it was a very injudicious use of the phrase "...requires user input..." in the normative text, because here I believe it simply means "needs" or "asks for". In other words, if there's an input, it needs to have a label. With that interpretation in mind, some of the phrases you are flagging, make a lot more sense, such as:
|
Previously Proposed Working Group answer:
This Success Criterion generally requires labels for form inputs so that users know what to put into a field, and instructions when a particular format is required. If some or all fields are required for submission, there can be different ways of indicating that, and the SC does not prescribe a particular method to do it. It could be done, for example, by
Other techniques are feasible and not ruled out by this Success Criterion. Please note that SC 3.3.2 Labels or descriptions has no Common Failure for not indicating that a field is required even if it is required (while it is clearly a recommended practice). As long as missing or erroneous input to a required field is programmatically detected during input or after submission, this would arguably not constitute a Failure of 3.3.2 Labels or descriptions (though if form submission fails and the user does not get an error message identifying the error or omission, this would clearly fail another Success Criterion, 3.3.1 Error identification). |
The proposed response that required fields don't need to be indicated seems to contradict previous advice from this group that fields which contain both optional and required fields would need to indicate either required or optional fields and not rely on form submission to provide that feedback unless they were something like a username/password field. Also, the convention of communicating required fields with an asterisk but without providing instructions of what that means is a debatable discussion regarding the same SC. I look forward to clarify from the working group on both of these as we need clear guidance that is consistent and clear in the understanding documentation. |
Opened #3622 |
TF discussion: @mbgower would like to refine the response. |
Official Working Group response:
First, it is important to emphasize the difference between the verb "requires" as used here and the adjective "required", as in "required field". This use of the word requires in the normative text is not intended to refer only to inputs that MUST be filled in in a form (i.e., the criterion is not only scoped for those inputs marked as required fields). Instead, requires is used in the sense of "needs" or "prompts for". In other words, the SC's main point is that if there's an input, it needs to have a label (or instructions). With that clarification in mind, some of the phrases you are flagging are not in contradiction with the normative language, such as:
All inputs need labels or instructions. The author decides in what manner the instructions and labels convey information (such as which fields must be filled in and which are optional). If some or all fields are required for submission, there can be different ways of indicating that, and the SC does not prescribe a particular method to do it. It could be done, for example, by
Other techniques (and combinations of the above) are feasible and not ruled out by this success criterion. Other criteria, such as 1.3.1 Info and Relationships and 3.3.1 Error Identification, also factor into discussions on accessible forms and inputs. |
I don't think the proposed response really clears up the question of whether forms need to state at all that any fields are required or optional. It also muddies the waters that perhaps in errors after form submission could be the place that any required/optional field indication is provided. Other SC such as 2.4.6 may also apply - but that's not clear either. |
Typo 1:
According to:
https://wcag.com/developers/3-3-2-labels-instructions/
We must:
“Make very clear which fields are required.”
However, within:
https://www.w3.org/WAI/WCAG21/Understanding/labels-or-instructions.html
It states that:
In a form which contains both required and optional fields, the required fields and/or the optional fields are clearly labeled as such.
I think it is not properly worded and can be misinterpreted that if no optional fields are in the form, it is not mandatory to label required fields.
Therefore it should say:
In a form which contains required fields, the required fields are clearly labeled as such.
OR
In a form which contains required and/or optional fields, both the required fields and/or the optional fields are clearly labeled as such.
The text was updated successfully, but these errors were encountered: