3.3.2 - Form control labels using non-text content #4626
Conversation
✅ Deploy Preview for wcag2 ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
| the task without undue confusion or navigation. | ||
| </p> | ||
|
|
||
| <p>Labels of form controls are usually text-based. In some cases, images can serve as descriptive labels without additional text. |
There was a problem hiding this comment.
| <p>Labels of form controls are usually text-based. In some cases, images can serve as descriptive labels without additional text. | |
| <p>Labels of form controls are usually text-based. Images with appropriate text alternatives can serve as labels without additional text. |
|
|
||
| <p>Labels of form controls are usually text-based. In some cases, images can serve as descriptive labels without additional text. | ||
| In these cases, authors should ensure that the image and its use as a label (in context) are widely understood.</p> |
There was a problem hiding this comment.
Suggest merging the two sentences just into one?
| <p>Labels of form controls are usually text-based. In some cases, images can serve as descriptive labels without additional text. | |
| In these cases, authors should ensure that the image and its use as a label (in context) are widely understood.</p> | |
| <p>Images (with an appropriate text alternative) can serve as descriptive labels without additional text. In these cases, authors should ensure that the image and its use as a label (in context) are widely understood.</p> |
There was a problem hiding this comment.
I prefer to point out "Labels of form controls are usually text-based.".
It makes clear that using labels is the exception, and that we are talking about forms here.
There was a problem hiding this comment.
I still fundamentally disagree that we need to make any kind of "this is common, this is the exception" statement here. That seems to add some sort of judgement on our part that has no business being here. Per the actual definition of label, it's "text or other component with a text alternative". No "but mostly text" or anything else. Adding qualifiers about what's "an exception" seems inappropriate to me.
| </p> | ||
|
|
||
| <p>Labels of form controls are usually text-based. In some cases, images can serve as descriptive labels without additional text. | ||
| In these cases, authors should ensure that the image and its use as a label (in context) are widely understood.</p> |
There was a problem hiding this comment.
I feel like this "widely understood" sentence would probably be better in Headings and Labels. Although it is goes beyond a simple discussion on descriptive text, the qualitative concepts of Headings and Labels seems like a better fit than the basic question of 3.3.2 which is: is there a label for the input?
Some task force members ended up having a long post-meeting discussion on the nuances of the telephone example in the original issue. It would be good to try to capture some of those concepts in our guidance, in some way.
There was a problem hiding this comment.
agree, the qualitative part should be moved to headings and labels (and, at a stretch, then cross-referenced from here)
|
After our after-hours chat last Friday, I've put together several codepen examples where the legend, combined with the visual context, should be (IMO) sufficient or where a visible label for each input may not be strictly necessary (though an accessible name is still required): https://codepen.io/giacomo-usablenet/full/vELaXpN We can review them together during our next meeting if you'd like. Note: These examples are only partially functional (if something doesn't work, just ignore it; the goal is to illustrate the concept). |
4 participants
Closes #3808
This PR clarifies the guidance regarding non-text content used as labels for form controls (re-used 2.4.6 wording). For example, in a form field set for phone numbers with country code and number, using a flag as the visual label may be sufficient, provided that a meaningful accessible name is also provided separately in accordance with SC 4.1.2.
This addresses the initial concern, but doesn’t cover the point raised by @amberhinds. It might be worth opening a separate issue, or we could discuss it first and decide on the best way to address it.