-
Notifications
You must be signed in to change notification settings - Fork 257
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clarification on 3.3.2: Does every input field need a persistent visual label? #4088
Comments
@cscheffauer Yes. Adding to your point, I would rely on the expectation of the user at the time of using the application/interface which is they reasonably expect that what type of data is being required at the form field. Generally, it is recommended to provide a persistent label for a form field to make the users understand that what sort of data input is required by the form field but here in chat/messenger application, the purpose of the edit field is expected by the user, so it is not required considering the context of the application. |
The definition of label allows a label to be non-text content such as an icon or even another control. So it's possible that a search button for example could label a search field. |
@mraccess77 Relatable to the 'Send Message' button in an edit field of a messenger/chat application what @cscheffauer has mentioned. The context of the button and sometimes the placeholder of the edit field is sufficient to let the users know that the particular edit field is for the compose message. A persistent label is not required here due to the context as users reasonably expect the type of data/inputs that the edit field require. Feel free to add your thoughts on this. |
Can we get this information somehow into the Success Criteria? Its very hard to argue about it just following the SC as it is at the moment. |
It's a fail if the answer to "is there a visible label" is "no" at any point. It's already in the SC. The SC does not mention exceptions to the requirement, so there are no exceptions to the requirement. |
@yatil thanks - so if there is a button which acts as a label the Success Criteria is met? |
Visual labels don't always need to be in close proximity- there seem to be sufficient techniques that imply that a visible label like phone number or social security number could be applied to multiple fields at once and pass. |
If a button in the form of an icon like a magnifying glass is acceptable as a label for a search field, then a button in the form of an icon like an arrow or paper plane should be acceptable as a label for a chat field. In both cases, the icon really represents what will happen to the input (it will be searched for, it will be sent) but that, in context, effectively satisfies the purpose of a label. Doesn't it? |
Can someone from the WCAG team confirm? Would like to get an official confirmation that having a button which acts as a label for the example mentioned above (Chat/Messenger) is sufficient to meet the SC. |
https://www.w3.org/WAI/WCAG21/Techniques/general/G167 and #3276 - Is that not enough? |
Based on sufficient techniques G167, Can we agree to close this thread as per the above provided references? 🤔 |
To be fair, an action item from this issue could be to provide another example in that technique of using an icon as a button "label" to pass this SC. G167 has a button with the word "search" in it - so i don't think it unreasonable at all for someone to not immediately think that an icon could be sufficient - there are those who have read the SC and the understanding doc and have misunderstood this |
Agreeing with @scottaohara - if I would have been searching around all Success Criterias and how they connect to each other, maybe it would have been clear to me - my expectation though is that WCAG specs are similarly accessible as they aim that their content is. So having a better description, more examples, possibly mentioning in the SC 3.3.2 about cases like I mentioned, would be really helpful and appreciated. |
According to my experience with people asking, I agree that examples are needed to illustrate the following statement made above: In fact, I suggest to add both examples: |
@gundulaniemann #4102 addresses your suggestions. |
For SC 3.3.2: Does every input field need a persistent visual label?
What about cases where a input field is used in a particular context, which might not be a form?
For example the WYSIWYG Text Editor in Chat / Messenger applications? It is technically a input, putting a visible label on the page is required by this SC - in a lot of cases it is weird in terms of UI / UX (the context of the messenger makes it clear that the input is for writing a message to someone).
Any guidance on this?
The text was updated successfully, but these errors were encountered: