Re: Icon and Icon Fonts: New thread

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

Wayne

On Tue, Mar 1, 2016 at 2:20 AM, Alastair Campbell <acampbell@nomensa.com>
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
>
>
>