RE: Obscure images as labels

My view is that this is not a WCAG non-conformance, although it is clearly bad UX.

SC 3.3.2 (Labels or Instructions) only applies to links or other controls that are associated with data entry, so it does not apply to components such as burger menu buttons and "Help" icons. Even in the context of data entry, it explicitly does not require that labels are sufficiently clear or descriptive.

SC 2.4.6 (Headings and Labels) requires that if headings or labels are provided, they be descriptive. However, WCAG defines a label as "text or other component with a text alternative", which means that images can be used as long as the text alternative is sufficiently descriptive.
https://www.w3.org/WAI/WCAG21/Understanding/headings-and-labels#dfn-label

This is obviously of no use to sighted people, but I guess the rationale is that people with disabilities are not at a greater disadvantage than anyone else. In fact, the text alternative means that it is more accessible to some people with disabilities than it is to anyone else.

Steve Green
Managing Director
Test Partners Ltd


From: Ms J <ms.jflz.woop@gmail.com>
Sent: Friday, June 14, 2024 11:20 AM
To: w3c-wai-ig@w3.org
Subject: Obscure images as labels

Hello

If I have a button and the visible label is an icon or image which is basically very abstract and it isn't possible to infer the purpose of the control from the icon alone, but the button has a clear accessible name, does this fail 'headings and labels' please? It almost feels as though there is no label at all if the label is just a useless image or icon that does not clearly indicate the purpose of the control, in which case I even think there's an argument that it fails 'labels or instructions'. I have seen icons for say 'settings' labelled by images of animals (because this image was the company logo) which is entirely unrelated to. The accessible name was 'settings' but this doesn't fail label in name as the label is an image.

Thanks

Sarah

Sent from Outlook for iOS<https://aka.ms/o0ukef>

Received on Friday, 14 June 2024 10:44:20 UTC