Re: Icon and Icon Fonts: New thread

Hi everyone,

Just as a follow up to the discussion on Unicode symbol usage, this link came up via @brucel:
http://unicode.johnholtripley.co.uk/all/


It shows support for Unicode symbols across browsers and some screen readers (Jaws/Win, VoiceOver/iOS, NVDA/Win, Chromevox).

The basic conclusion from that table is that the Unicode descriptions (e.g. “Smiley face”) cannot be relied on. VoiceOver on iOS appears to have the best support, but even then only a small proportion of the symbols are announced.
In NVDA only “check” is announced, the others are not announced at all so would be invisible.

Therefore even if the symbols and descriptions were static and valid across font-faces, there is so little support from screen readers they are not viable as alt-text equivalents.

Cheers,

-Alastair


From: Wayne Dick
Date: Tuesday, 1 March 2016 at 15:37

Thanks for all of the comments. I think I agree that it exceeds the WCAG text, but requires visibility.
Wayne

Alastair Campbell wrote:
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