Wcag: Do icons / images without visible text fail 2.4.6 Headings and Labels, always?

[jake-abma]

2.4.6 says:

Headings and labels describe topic or purpose.

Labels have the definition of:

label
text or other component with a text alternative that is presented to a user to identify a component within Web content

icons and images without visible text are / can be "other component with a text alternative" BUT they do NOT "describe topic or purpose" to the sighted user...

... thus always failing?

So a magnifying glass (with proper text alternative) next to a search input without text will FAIL.

I guess this SC is not only for 'some people', like the ones using a screen reader (meaning this SC is like Headings and labels describe topic or purpose == to all users ==

[jake-abma]

also the intent talks about:

it provides an appropriate cue

... and it is enough (?!)

Is an "appropriate cue" by definition "descriptive"? This seems like an escape for many cases where we probably don't mean an "appropriate cue" but really that it is "descriptive" which seems a bit apart from each other.

[jake-abma]

3: and...

while failing this Success Criterion (if those headings or labels are not sufficiently clear or descriptive)

This sentence says: "not sufficiently clear or descriptive"

The "or" suggests that there are two ways to measure: "not sufficiently clear" and "descriptive" which is not part of the normative text

Summing up we now have "not sufficiently clear", "descriptive", and "an appropriate cue"

[jake-abma]

4: don't we want something like this in a SC based on 2.4.9: Link Purpose (Link Only)

A mechanism is available to allow the purpose of each link to be identified from link text alone

But now for icons in 2.4.6:

A mechanism is available to allow the described topic or purpose of each icon / graphic in a label without visible text to be identified from the text alternative

[awkawk]

@jake-abma 2.4.6 doesn't require that labels are always present, just that when you have a label or a heading that it describes the topic or purpose.

Icons without visible text can describe a button (e.g., a magnifying glass for a search field).

Part of what I think you are getting at is what 1.3.6 Identify Purpose was created to address.

[bruce-usab]

I have come to understanddescribe topic or purpose as being equivalent to descriptive identification. I guess because my mind is too small to have _three_ tiers of text equivalent qualities?

It might be good if WCAG 2.999 were to have 2.4.6 read:

Headings and labels provide descriptive identification.

[jake-abma]

What about

Headings and accessible names provide descriptive identification.

?

[JAWS-test]

Headings and accessible names provide descriptive identification.

I would think that this is wrong, because then the visible labels would no longer be relevant

[bruce-usab]

+1 to @JAWS-test above since 2.4.6 is about visible identifies.

But the idea does make me want to ask:

1. Is the WCAG2x glossary term for name (text by which software can identify a component within Web content to the user) broad enough to encompass ARIA accessible name? I think so, but I find that curious!
2. On a recent AG WG call, we brainstormed a bit about potential SC for a potential WCAG 2.3. Should there be an SC specifically for ARIA accessible name? Is there a currently a gap?

[jake-abma]

-1 to @JAWS-test

When the label is text this WILL become the accessible name!

but for an icon... it depends on what we mean with "describe", I always thought "describe" means it "describes" the topic or purpose NOT it's giving a cue, this is NOT descriptive in my dictionary.

So, IF an icon has a magnifying glass for search (obvious for many, not for others...) is that "descriptive enough? Is it a cue? Are those mean the same thing? Or you only look at the alternative text? (accessible name)

If so, is "magnifying glass" good as ACC name? descriptive? enough for a cue? OR must it be something like "Search"...?!

If the latter, why is the visual magnifying glass OK, and as alternative text not? The cue is fine.

This is the same for all other icons, where 95%, maybe 99% of icons out there are not clear to most people

[jake-abma]

Maybe

Headings and labels of text describe topic or purpose.

?

[awkawk]

When the label is text this WILL become the accessible name!

Not necessarily. In the example below, the label is Name and the Accessible name is Email. If you mean "When the label is text and is programmatically associated with the input this will become the accessible name" then I agree.
<label>Name</label><input type="text" aria-label="email">

but for an icon... it depends on what we mean with "describe", I always thought "describe" means it "describes" the topic or purpose NOT it's giving a cue, this is NOT descriptive in my dictionary.

So I'm gathering that this is the main point - whether a label is descriptive. I can agree that "search" isn't descriptive of the image in the search bar example, but as a label for the input I think that it is descriptive.

I think that it is helpful to look at the definition of label:

text or other component with a text alternative that is presented to a user to identify a component within Web content

This clears indicates that a label can be an image, and that it is used to identify the component. So I don't think that the normative text needs to say anything different.

[jake-abma]

@awkawk wrote:

Icons without visible text can describe a button (e.g., a magnifying glass for a search field).

this is exactly what I dispute above...

does 'describe' in this case mean 'represent a cue'?

That would be very weak and might open the door to all headings and labels be 'labelled' as a cue, diminishing the impact of the SC.

Last time I checked icons do not work around the world to make lots of stuff descriptive, in the contrary, they more often cause confusion. We had 250 of them in our library once and I did not understood 90% of them, also as an example the icons in the Silver document raised lots of questions.

Will a magnifying glass, home, and email (depending on the design) be the ONLY ones understood in general...?

[mraccess77]

Seems like the descriptive label should apply to icons being descriptive as well. Just because I use an icon doesn't mean it is descriptive - although measuring how descriptive an icon is may be more complex. Also of note it is worth us agreeing if this applies just to visual aspects like SC 3.3.2 and not to the accessible name as well. My understanding was that this SC was about the visual labels only and anything related to programmatic name would fall under SC 1.3.1 or SC 4.1.2 (text related), SC 1.1.1 (non-text related).

If we are looking for new SC for a WCAG 2.3 then one to require text for icons be available through some mechanism might be good.

[bruce-usab]

It's pretty easy to think of examples where an icons (without visible text) are perfectly sufficient to describe topic or purpose. This GitHub text box widget is using 9+ of them.

With regard to description versus describe purpose, it is similar to ALT where a picture of a lens on a stick should (almost certainly) be associated with search (and _not_ magnifying glass) and best ALT for a thumbnail picture of a personal dwelling is home and _not_ house.

Edit to note that @awkawk wrote but as a label for the input I think that it is descriptive. Agreed!

[awkawk]

@bruce-usab

Is the WCAG2x glossary term for name (text by which software can identify a component within Web content to the user) broad enough to encompass ARIA accessible name? I think so, but I find that curious!

Absolutely. It is all up to what is exposed via the Accessibility API as the programmatic name. If I were able to convince browsers that a custom attribute value should map to the accessibility name in the API, then that would work also.

[jake-abma]

@bruce-usab wrote:

This GitHub text box widget is using 9+ of them.

and:

perfectly sufficient !!!

Sorry Bruce, after 5 years I still don't know them as they are NOT descriptive, I can imagine people with cognitive issues have even more problems understanding

[scottaohara]

I have also found this SC to cause a lot of confusion with people - particularly around the definition of label being "text or other component with text alternative". the 'text alternative' bit making people think this SC is about the quality of that as well.

If this is about how understandable the visible representation of the heading or label are - then it would be very helpful to explicitly say that. Right now, as this thread illustrates, it's not completely clear if text alternatives fall under this SC as well when an icon is serving as a label or heading.

My general read of this has been no, descriptive text alternatives do not belong here. If the alternative text of an icon isn't clearly indicating it's purpose, then that's a failure of 1.1.1.

Following on with the examples here already, a magnifying glass representing the visible "label" for a search field would be sufficient under 2.4.6. An icon of a light bulb as the visible "label" for a search field would fail this SC.

But, a magnify glass icon with the accessible name "magnify glass", which provided the accessible name to the submit button, for a search field, would then fail 1.1.1. The visible "label" is "clear" in this instance (arguments about general understanding of common icons aside). But the alternative text that provides the button its accessible name is not descriptive of its purpose, in this context.

[awkawk]

@jake-abma

That would be very weak and might open the door to all headings and labels be 'labelled' as a cue, diminishing the impact of the SC.

I don't get the distinction between cue and description. Do you really want a robust description for each heading on a page? You might say that "Products" is more of a cue than a description if you get very particular about descriptions needing to be more descriptive. I read this to indicate the need for a very spartan description. I certainly don't want a product section heading to be "Product section, providing information about 50 products and links to trail downloads for each". :)

Last time I checked icons do not work around the world to make lots of stuff descriptive, in the contrary, they more often cause confusion. We had 250 of them in our library once and I did not understood 90% of them, also as an example the icons in the Silver document raised lots of questions.

There is a learning curve for icons, and end users can learn what they mean when you hover or focus the icon. Right now WCAG doesn't require visible text labels for icons, but this is something that the WG can discuss. I expect we would encounter a lot of resistance on this idea since it would have a major impact on designs.

[awkawk]

@scottaohara

But, a magnify glass icon with the accessible name "magnify glass", which provided the accessible name to the submit button, for a search field, would then fail 1.1.1. The visible "label" is "clear" in this instance (arguments about general understanding of common icons aside). But the alternative text that provides the button its accessible name is not descriptive of its purpose, in this context.

A magnifying glass icon with the accessible name "magnify glass" that is used as a search submit button would fail 2.4.6 (not describing the purpose) and it would fail 1.1.1 because it is an image on a control and "magnify glass" doesn't describe the purpose. So I think we are agreeing?

Controls, Input
If non-text content is a control or accepts user input, then it has a name that describes its purpose.

[jake-abma]

@awkawk wrote:

because it is an image on a control and "magnify glass" doesn't describe the purpose. So I think we are agreeing?

Huh, now it doesn't describe purpose? and fails? while visual you see a magnifying glass and passes?

[mraccess77]

So if accessible names are covered - then if I had buttons in cells of a table to edit the cells with only an accessible name of "edit" - could I rely off of of the table header cells to provide the accessible name in context or does the accessible name need to include those directly via aria-label, aria-labelledby etc. not relying on associated table header cells? We are straying into territory similar to SC 2.4.4 for Link purpose.

[awkawk]

@jake-abma Ok, maybe I'd uncomfortably look past a button with the icon that serves as the label for a search field if the alt on the icon was "magnify glass". I think that would be a poor choice because it doesn't really describe the purpose of the control, it describes the image on the control. Some might say "why is the image of a magnifying glass sufficient as a visible label for sighted users but that text isn't sufficient for non-sighted users?" and my response is that this is an established pattern for signed users but I don't think that it is for non-sighted users.

Really to settle that question we would need user testing. @mraccess77 would you expect that a search button be labeled "search" or "magnify glass"?

[scottaohara]

@awkawk it depends on if 2.4.6 is concerned with the visible label / heading, or if it is also concerned with the alternative text / accessible name of any non-text content that could be used as a visible "label / heading"

If only concerned with the visible representation of the label, then poor alternative text for an image in context should be covered by 1.1.1 alone. Just like how 3.3.2 only cares about if a label is present, but associating it with the form control is covered by other SCs.

If 2.4.6 is also concerned with accessible names / alternative text of non-text labels/headings, then yes I would unfortunately agree that 2.4.6 would apply... but that seems redundant to what 1.1.1 should already cover. - and again, is presently confusing people with this SC.

[mraccess77]

I'd expect a magnifying glass icon to have an accessible name of something like "find", "search", or "locate", etc. but not magnifying glass. This would fail under SC 1.1.1 - but people seem to not agree on whether it also fails SC 2.4.6. Generally people don't fail SC 3.3.2 when something has a visible label but no programmatic label - but perhaps we need to figure out a consistent approach to all of these where multiple SC could fail.

[patrickhlauke]

From the thread starter:

icons and images without visible text are / can be "other component with a text alternative" BUT they do NOT "describe topic or purpose" to the sighted user...

... thus always failing?

I would say no, it's not always failing, if the icon/image is sufficiently clear/understandable to provide a sighted user with enough information/enough of a clue about what the purpose of something is.

Is it a fuzzy, perhaps subjective thing to evaluate? sure. But it's also fuzzy if it were actual text, in many cases.

If the image/icon lacks a (proper) text alternative, then it will fail 1.1.1. if it has a text alternative, but icon/image is used as a label, and the alternative is not (subjectively found to be) sufficiently good at conveying "topic or purpose", then yes fail it.

but to outright say that icons/images used as labels fail 2.4.6? Nah...don't think so.

[awkawk]

@mraccess77

So if accessible names are covered - then if I had buttons in cells of a table to edit the cells with only an accessible name of "edit" - could I rely off of of the table header cells to provide the accessible name in context or does the accessible name need to include those directly via aria-label, aria-labelledby etc. not relying on associated table header cells? We are straying into territory similar to SC 2.4.4 for Link purpose.

I'd pass them with "edit" as the label. Here's my thought process:
1) Can people get the full context for those buttons? Yes, but it requires additional navigation to get that context - that's not ideal.
2) Perhaps we could use ARIA-label or -labelledBy to augment the accessibility name for the buttons.
3) That could get really long depending on the table heading content that we add to the edit button. Maybe it makes sense to use aria-describedBy so that information is last and skippable?
4) If we are using aria-describedBy we aren't really modifying the name, we are modifying the description, so maybe the "edit" is sufficient.

[patrickhlauke]

Generally people don't fail SC 3.3.2 when something has a visible label but no programmatic label - but perhaps we need to figure out a consistent approach to all of these where multiple SC could fail.

didn't we clarify this in the understanding document (it might even have been me who pushed a change/addition here, it certainly feels like something I might have written)?

https://www.w3.org/WAI/WCAG21/Understanding/labels-or-instructions.html

Further, this Success Criterion does not take into consideration whether or not alternative methods of providing an accessible name or description for form controls and inputs has been used - this aspect is covered separately by 4.1.2: Name, Role and Value. It is possible for controls and inputs to have an appropriate accessible name or description (e.g. using aria-label="...") and therefore pass Success Criterion 4.1.2, but to still fail this Success Criterion (if the labels or instructions aren't presented to all users, not just those using assistive technologies).

(i might even say this should also mention 1.3.1, as it can straddle the line of info and relationships too)

[mraccess77]

@awkawk I would agree with you on controls in tables. As long as there are row and column headers (which only apply to content after them - to the right in English for row headers) then screen reader users can press keystrokes to read the associated header cells without navigation. Adjusting an accessible name to something that is verbose is not helpful and aria-describedby is a good advisory best practice but doesn't seem required unless row& column are not marked.

[patrickhlauke]

Just to bring it back to the original question "Do icons / images without visible text fail 2.4.6 Headings and Labels, always?" can we agree that the answer is... no?

[patrickhlauke]

we can then probably have some more nuance that we also hopefully agree on:

• if the icon/image is used as a label and is (subjectively) appropriate to visually convey the purpose (e.g. a magnifying glass icon for search), and it has an appropriate text alternative that also conveys the purpose, it passes 2.4.6
• if the icon/image is used as a label, has alternative text that (subjectively) conveys the purpose correctly, but uses some really cryptic/hard to understand visual that is unlikely to be obvious to any sighted users - this fails 2.4.6
• if the icon/image is used as a label, is (subjectively) appropriate to visually convey the purpose (e.g. a magnifying glass icon for search), but lacks a text alternative altogether or has a text alternative that *subjectively) doesn't convey the actual purpose/work as a label (alt="chicken"), it fails both 1.1.1 and 2.4.6 (a "cascade of fail")