- From: John Foliot <john.foliot@deque.com>
- Date: Mon, 29 Feb 2016 15:27:07 -0600
- To: "'Gregg Vanderheiden'" <gregg@raisingthefloor.org>, "'GLWAI Guidelines WG org'" <w3c-wai-gl@w3.org>
- Message-ID: <005a01d17337$f190a8c0$d4b1fa40$@deque.com>
At the risk of opening another can of worms, I think we should also recognize the difference between “icons” and “iconography” in the context of the discussion regarding contrast.
I will argue that iconography that is a call-to-action, which may or may not be provided as a text glyph (aka wingdings, etc. - perhaps ⌂) or via a PNG or other graphic file (the image of a light gray printer) are functionally the same when it comes to requiring sufficient contrast for low-vision users: if they represent a call-to-action then they should have enough contrast to be Perceivable. Currently today, WCAG is silent on these types of use-cases – nowhere does it address that light-gray “printer.png”.
As far as WCAG 2.0 is concerned, I’ll argue that this is a gap that cannot (and should not) be redefined in the context of 2.0. The understood definition of text contrast in 2008 is what should stand.
This gap CAN be addressed with an extension to WCAG, and I’d even suggest that this point should be addressed in either the Low Vision TF or perhaps the Mobile TF (or both). I will suggest that the key is the notion of a “Call-to-action”, either as a link or a button (which would help satisfy part of the testable statement requirement).
JF
From: Gregg Vanderheiden [mailto:gregg@raisingthefloor.org]
Sent: Monday, February 29, 2016 2:55 PM
To: GLWAI Guidelines WG org <w3c-wai-gl@w3.org>
Subject: Re: Color Contrast (was RE: Coming to a decision on 2.2 - which has long since been lost in this thread)
I will join Loretta in retiring from this discussion unless a new question comes up.
In summary
1. icons are not text. There may be SOME icons that are used in a sequence to form a natural language - but most icons are not used this way.
* (You COULD define something less than icons to be text — e.g. “iconographic text” like bliss symbols — but icons as a whole are not used in sequence to communicate.
2. 1 item is not a sequence.
3. it would be nice to see some icons made simpler and high contrast. But this is not possible or desirable for all icons.
4. due to the physics and math of icons — you cannot have more than two colors and have 4.5:1 contrast ratio with the background and each other. And even then the background has to be near black or near white — and one of the other two colors must near white or black with the third taken from a colors near 4.5:1 contrast from the background and the other color. So colored icons will be very limited if the text contrast rules are applied.
gregg
On Feb 29, 2016, at 1:51 PM, Loretta Guarino Reid <lorettaguarino@google.com <mailto:lorettaguarino@google.com> > wrote:
I think I've contributed all the information I have to this discussion.
This is an important (and difficult) topic, and I trust the Working Group will find the best way to address it. After all, I can't see those washed out icons, either. <grin>
Loretta
On Mon, Feb 29, 2016 at 11:38 AM, Kurt Mattes <kurt.mattes@deque.com <mailto:kurt.mattes@deque.com> > wrote:
Perhaps I am mistaken. The topic is color contrast, which is 1.4.3 and includes images of text. 1.4.3 does not mention programmatically determinable.
1.4.3 does not mention programmatically determinable, but the definition of text in the glossary does.
And if the Working Group decides that the definition of text covers icons, then you will need to consider the ramifications for all Success Criteria, not just for 1.4.3.
Icon fonts introduce another wrinkle. IMHO icons don't need to be fonts to be considered text. The normative (and unchangeable) definition of text in WCAG 2.0 speaks about characters. WCAG does not exclude characters or text of an obscure language where no fonts currently exist.
WCAG 2.0 does not define the word characters therefore it is left to definitions found in reliable dictionary sources. According to those definitions, an icon is a type of character. That may not align with what was intended, but it is what WCAG normative language says.
Greg - I respectfully disagree. Icons are characters and characters are text, therefore, icons are text. When they are rendered as images then they are images of text.
On Mon, Feb 29, 2016 at 1:25 PM, Jonathan Avila <jon.avila@ssbbartgroup.com <mailto:jon.avila@ssbbartgroup.com> > wrote:
* And that's why I asked how we programmatically determine the meaning of an icon.
There are Unicode characters that represent many icons in a standard way albeit differences between platforms and some fonts that repurpose the codes for different purposes. There are also private use areas of Unicode.
* There are lots of variant appearances of even common icons like search.
But they generally mean “search” even if they appear slightly different.
VoiceOver on iOS supports many icon fonts and based on the Unicode will speak a textual equivalent for the images. Sometimes these have been repurposed and the result is quite funny – but the fact is there is a Unicode value that is assigned a standard meaning and Apple is using that now with VoiceOver and platforms use those values to display characters across platforms in similar ways. Many people text with emoji now these are certainly characters as well and are supported cross platform some to some consistent degree with artistic license.
Jonathan
From: Loretta Guarino Reid [mailto:lorettaguarino@google.com <mailto:lorettaguarino@google.com> ]
Sent: Monday, February 29, 2016 2:15 PM
To: Wayne Dick
Cc: Gregg Vanderheiden RTF; Kurt Mattes; John Foliot; Léonie Watson; Katie Haritos-Shea; David MacDonald; Jason J White; Sailesh Panchang; Andrew Kirkpatrick; GLWAI Guidelines WG org
Subject: Re: Color Contrast (was RE: Coming to a decision on 2.2 - which has long since been lost in this thread)
And that's why I asked how we programmatically determine the meaning of an icon. Perhaps if they were standardized (and supported) in the Unicode space? There are lots of variant appearances of even common icons like search.
On Mon, Feb 29, 2016 at 11:09 AM, Wayne Dick <wayneedick@gmail.com <mailto:wayneedick@gmail.com> > wrote:
The meaning of normative definitions is not what WCAG WG decides, or what the committee meant in 2008. The standard is out there. Icons from icon fonts that appear in web pages today meet the definition of text. The definitions is:
text
sequence of characters that can be programmatically determined <https://www.w3.org/TR/WCAG20/#programmaticallydetermineddef> , where the sequence is expressing something in human language <https://www.w3.org/TR/WCAG20/#human-langdef>
Icon fonts have well defined human language meanings and they can be programmatically determined. The fact that they are one character sequences is not unusual. The words: "I", "a", "0, 1, ..., 9", and all single character punctuation are one character sequences that are part of text. In the past decade web technology has just created new text that fits the definition. Language changes all the time. That's why we update dictionaries.
Wayne
On Mon, Feb 29, 2016 at 9:52 AM, Gregg Vanderheiden RTF <gregg@raisingthefloor.org <mailto:gregg@raisingthefloor.org> > wrote:
Icons are not text according to the definition in WCAG 2.0.
They may be text in some other context - but the definition in WCAG 2.0 was not intended to cover icons — and definitions are normative - so they can’t be re-interpreted after public review and adoption.
gregg
On Feb 29, 2016, at 7:27 AM, Kurt Mattes <kurt.mattes@deque.com <mailto:kurt.mattes@deque.com> > wrote:
I mostly agree with Wayne. Icons are text, however according to Merriam-Webster the first known use of icon occurred in 1572. Perhaps one of the more recognizable early icons is the skull and crossbones.
The normative language of WCAG 2.0 addresses icons, as long as one is willing to accept the common definitions of the words that are used. >From the online Merriam-Webster dictionary:
Character (definition 1b): a graphic symbol (as a hieroglyph or alphabet letter) used in writing or printing
Icon (definition 5a): a sign (as a word or graphic symbol) whose form suggests its meaning
Both an icon and a character are graphic symbols, used in human language. Both can be used in human language since the form of both can and do convey meaning to humans. Icons are and for centuries have been a type of character or text. I would venture to say icons may be the most universal human language or text on the planet.
Yet somehow some people who apply WCAG and even some who crafted WCAG seem to believe icons and text are different things. If this false distinction is truly what the framers of WCAG desired, then the word "character" in the normative definition of "text" would also need to be defined to exclude icons. Since "character" is not defined by WCAG, then by common definition any part of WCAG relying upon the word "text" as defined by WCAG must also apply to icons.
On Sun, Feb 28, 2016 at 2:11 PM, Wayne Dick <wayneedick@gmail.com <mailto:wayneedick@gmail.com> > wrote:
1.4.3 already applies to icons.
The term text is defined to be:
sequence of characters that can be programmatically determined <https://www.w3.org/TR/WCAG20/#programmaticallydetermineddef> , where the sequence is expressing something in human language <https://www.w3.org/TR/WCAG20/#human-langdef> .
Now, ten years past icons would not fit into this description, but today we have true iconic text: the search glass, trash can, tool wheel, attachment paper clip, close window x, minimize underscore, maximize box, house for homepage, hamburger for menu etc. We can easily develop an alphabet of programmatically deterministic icon symbols that are in common use today, and it is large.
A sequence can include only one element, like the number 1, or an icon used for programmatically deterministic linguistic purpose. Therefore, a lot of the icons we see today are in fact text. They may not have been text when 1.4.3 was formulated, but they are now. Technology changes. The reason this was overlooked at the time is because standard uses of icons had not coalescing so definitively 2008. Mobile devices had a lot to do with this with their standardization to fill the need to save space. What we have today is an icon language that needs to be treated like what it is, well defined symbols that convey human language.
On Mon, Feb 22, 2016 at 4:37 PM, John Foliot <john.foliot@deque.com <mailto:john.foliot@deque.com> > wrote:
…and yet, as we’ve seen already on this thread, increasing contrast negatively affects other user-groups (COGA), which effectively leaves us with a real dilemma: how do we address the needs of both groups? Can it be done simultaneously? Is color contrast issues an outlier here, or do we envision other emergent SC that may cause the same or similar discrepancies?
Off the top of my head, I could perhaps envision a new Success Criteria that says something along the lines of “Page Content [sic] MUST allow the end user to adjust contrast between the ranges of ___ (whatever is a reasonable low-end for COGA needs) and ___ (whatever is a reasonable high-end for LV, etc.)” - in other words mandating customization-ability of the page/site in question. One possible Technique would be to offer the end user the ability to select a “skin” or color scheme upon first visit (with perhaps setting a cookie to remember the user’s choice?... I don’t know, I’m thinking out loud here…)
What I would certainly bristle at however would be something along the lines of:
SC 1.4.3 (and/or)
SC 1.4.3.1LV (and/or)
SC 1.4.3.2COGA (and/or)
SC 1.4.3.3MOBILE
…that to me is a recipe for confusion and non-adoption.
(Slightly off-tangent – for a thread already way off tangent – I *could* envision “extending” SC 1.4.3 to cover icons and other key actionable graphics on a page, which is currently not covered at all by WCAG 2.0: now *THAT* I could see as a SC 1.4.3.1 sub-set/sub-section)
JF
From: Léonie Watson [mailto:tink@tink.uk <mailto:tink@tink.uk> ]
Sent: Monday, February 22, 2016 4:17 PM
To: 'John Foliot' <john.foliot@deque.com <mailto:john.foliot@deque.com> >; 'Katie Haritos-Shea' <ryladog@gmail.com <mailto:ryladog@gmail.com> >
Cc: 'David MacDonald' <david100@sympatico.ca <mailto:david100@sympatico.ca> >; 'CAE-Vanderhe' <gregg@raisingthefloor.org <mailto:gregg@raisingthefloor.org> >; 'Jason J White' <jjwhite@ets.org <mailto:jjwhite@ets.org> >; 'Sailesh Panchang' <sailesh.panchang@deque.com <mailto:sailesh.panchang@deque.com> >; 'Andrew Kirkpatrick' <akirkpat@adobe.com <mailto:akirkpat@adobe.com> >; 'GLWAI Guidelines WG org' <w3c-wai-gl@w3.org <mailto:w3c-wai-gl@w3.org> >
Subject: RE: Coming to a decision on 2.2
From: John Foliot [mailto:john.foliot@deque.com]
Sent: 22 February 2016 19:20
"The fact that a TF that is looking specifically at issues related to Low Vision users (or Cognitive users, or Mobile users – which sort of is everybody) helps bring focus to those types of needs, and ensures that the next-gen WCAG addresses shortcomings that specifically affects that group, but I will suggest that increasing the contrast requirements [sic] will benefit not only LV users, but perhaps Mobile users and Seniors as well, so making it a “Low Vision” Success Criteria in name feels (to me) wrong."
+1
I think it will also cause confusion. The 2.0 SC is intended to provide sufficient contrast for people with low vision. If an extension SC provides a better recommendation, it will effectively render the original SC obsolete.
Updating guidance is progress and is a good thing (in many respects it's already long overdue), but trying to have conflicting SC exist in the same time/space seems like we're asking for trouble.
Léonie.
--
@LeonieWatson tink.uk <http://tink.uk/> Carpe diem
--
Regards,
Kurt Mattes
Senior Accessibility Consultant - Deque Systems
610-368-1539 <tel:610-368-1539>
--
Regards,
Kurt Mattes
Senior Accessibility Consultant - Deque Systems
610-368-1539 <tel:610-368-1539>
Received on Monday, 29 February 2016 21:27:43 UTC