RE: Icon and Icon Fonts: New thread

Wayne Dick wrote:

> 

> 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?

 

Wayne,

The main thrust in my argument is that it shouldn’t matter *how* the developer has provided the iconography in any given page. If the point of the iconography is to convey a message, and specifically that the iconography wants the end user to *DO* something, then the contrast of that iconography should come into play. 

 

Today it doesn’t.

 

> If icons images are used in a standard way to express language and have no
> equivalent icon font value are they really text?

 

As far as contrast is concerned, why does it matter? Serious question – who cares how the iconography is supplied; the accessibility question we should be asking is, can all users Perceive it? We need to be a bit more technology agnostic here, and not get dragged into the weeds over which side of the discussion around “Tastes Great, Less Filling” individuals fall.

 

> If an icon image is the same an icon font value and has a generally agreed upon
> meaning, is it an image of text?

 

The problem is the use of the term “icon”. What about an .ico file – is that in scope as well? I fear this is becoming a forest and trees discussion, when what we should be focused on is the net result for the end user (who neither knows or cares how you’ve put that icon on the page).

 

If a website uses an .ico file for favicon in the header, then yes, there SHOULD be sufficient contrast, but failing to do so really doesn’t harm the end user.

 

If a form of imagery (.png, .ico, font-face glyph) is used to denote an action, and programmatically is used that way (because it is wrapped inside of an <a>nchor tag, or has the role of button), then it MUST be evaluated under the same requirements of “text” – except today we can’t fail a web page for that. 

 

At best, we can point to requiring a visible tab focus, but as Paul Adam noted, WCAG has a gap there too, as the native dotted outline, when used over a dark background also fails at a functional level, yet is within the conformance language of the current WCAG 2.0. 

 

However, returning to that imagery or iconography, it cannot be explicitly linked to a specific Success Criteria today, because the only SC that talks about contrast are those that reference text only.

 

Attempting to redefine or improve the definition of text in WCAG 2.0 will materially change how WCAG has been interpreted and used these past 7 years, and will be subject to massive push-back. 

 

> I think according to the WCAG 2.0 glossary the answer is yes, no, yes.

 

Very strictly speaking, perhaps the answer to the first question is yes. But how do you come to a testable statement that defines “well defined meaning”? Does a magnifying glass mean Search or Enlarge? What does a question mark inside of a circle mean? 

 

When you start using images as a visual short-hand, there are all kinds of add-on questions related to location, language, and cultural constructs that makes  this tricky… it’s kind of like defining Community Standards: different communities have different Standards. (Facebook has this problem today: Their “Like” icon. The positive “thumbs up” in Western cultures is a big no-no in other countries, such as Greece, Italy, and some locales throughout the Middle East. It’s essentially the equivalent of the middle finger. - http://www.ethos3.com/2014/07/dont-give-a-thumbs-up-in-russia-and-other-hand-gesture-facts/) 

 

> 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.

 

While I agree that we need new Success Criteria, whether or not they are special fail cases for 1.4.3 or whether they are addressed by a new Success Criteria remains another unanswered question, but I think where we both are in agreement is that there is a gap today.

 

JF

 

Received on Monday, 29 February 2016 22:25:22 UTC