RE: Icon and Icon Fonts: New thread

Hi Alistair

Great summary! I think you’ve captured the most important accessibility and usability issues related to icons.

I agree that this must be addressed in an extension and not by trying to re-interpret the WGAG 2.0 by stating that icons are text (which Gregg has clearly argued is almost never the case).

The LVTF would seem to be the best place to start to address this (even though, as you have explained, the “problems” with icons are not just an LV issue).

Best regards

Mike

From: Alastair Campbell [mailto:acampbell@nomensa.com]
Sent: 01 March 2016 10:20
To: Wayne Dick <wayneedick@gmail.com>
Cc: GLWAI Guidelines WG org <w3c-wai-gl@w3.org>
Subject: Re: Icon and Icon Fonts: New thread

Hi Wayne,

I’m generally of the opinion that the contrast of icons should be covered, but it isn’t by WCAG 2. The LVTF would be a good place to address it.

There are two points I’d raise about icons and text equivalence:

1. Very few icons have a universally, or even widely understood meaning. For example: Is the magnifying glass for search, or zoom? Once you get past the house = home icon, there are virtually no widely recognised icons you can rely on. In testing I regularly see people not understand the hamburger  = menu, or three dots = context menu. And these are widely used! Icons for word-processing functionality are reasonably recognised, unless you take them out of that context.

2. I don’t think there is an ability to programatically understand what icons mean except by text-alternatives. Font icons do map to unicode locations, however, if you change the font (e.g. Wingdings to some other font) any meaning is then wrong. The same unicode location is used for different symbols in different fonts. If they require text alternatives, they aren’t text.
SVG is gaining popularity as a good way to do icons, and that also requires text alternatives unless it is actually text.

Sidenote: I think emojis have a more standard vocabulary, but until they start getting used on sites in a standard way, that doesn’t help. I’d come back to the usability point as well, I might just be getting old but I sometimes have to turn on VoiceOver on my phone to understand what they mean. It was a while before I understood what the brown triangle was…

Icons (of whatever contrast) cause a problem for many people when:

  *   It is an icon only, with no text as part of the same element.
  *   It is something that requires understanding or action.
Added accessibility issues are:

  *   The developer assumes that for accessibility they just need a text-alternative for a screenreader, so apply a alt text or title. (Issue for keyboard users, possibly others.)
  *   Low contast makes the problem of seeing and understanding the icon harder.
Are there other issues I haven’t thought of?

For the low contrast aspect, I think that you could construct a new SC that says something equivalent to “Where icons are used for navigation or functionality without associated visible text, it must have sufficient contrast against the background colour.”

Taking on board Gregg’s point about multi-coloured icons with varying contrast, I would say that some elements of it should have sufficient contrast against the background, but not necessarily all, and not within itself. The issue is knowing it is there (contrast), and then it must have a means of working out what it means for everyone.

Cheers,

-Alastair


From: Wayne Dick
When do icons become characters of text?
Is a character in an icon font that has a well defined meaning like the search glass a character in text?
If icons images are used in a standard way to express language and have no equivalent icon font value are they really text?
If an icon image is the same an icon font value and has a generally agreed upon meaning, is it an image of text?
I think according to the WCAG 2.0 glossary the answer is yes, no, yes.
But the second is really generally accepted information conveyed by an image that is not programmatically determined.
1.4.3 applies the first class. No question.
The last two situation should have a special fail case for 1.4.3.
Wayne