Re: Color Contrast (was RE: Coming to a decision on 2.2 - which has long since been lost in this thread)

Yes, when rendered with an image element containing an alt attribute with
appropriate alt content.

On Mon, Feb 29, 2016 at 12:29 PM, Loretta Guarino Reid <
lorettaguarino@google.com> wrote:

> Is the meaning of an icon programmatically determinable? How will AT know
> what icon is present?
>
> On Mon, Feb 29, 2016 at 10:06 AM, Wayne Dick <wayneedick@gmail.com> wrote:
>
>> Icons were not text in 2008. They are now. They are sequences of
>> characters that can be programmatically determined that refer to human
>> language. (note especially icon fonts.)
>>
>> On Mon, Feb 29, 2016 at 9:52 AM, Gregg Vanderheiden RTF <
>> 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> 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>
>>> 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>
>>>> 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]
>>>>> *Sent:* Monday, February 22, 2016 4:17 PM
>>>>> *To:* 'John Foliot' <john.foliot@deque.com>; 'Katie Haritos-Shea' <
>>>>> ryladog@gmail.com>
>>>>> *Cc:* 'David MacDonald' <david100@sympatico.ca>; 'CAE-Vanderhe' <
>>>>> gregg@raisingthefloor.org>; 'Jason J White' <jjwhite@ets.org>;
>>>>> 'Sailesh Panchang' <sailesh.panchang@deque.com>; 'Andrew Kirkpatrick'
>>>>> <akirkpat@adobe.com>; 'GLWAI Guidelines WG org' <w3c-wai-gl@w3.org>
>>>>> *Subject:* RE: Coming to a decision on 2.2
>>>>>
>>>>>
>>>>>
>>>>> *From:* John Foliot [mailto:john.foliot@deque.com
>>>>> <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 Carpe diem
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Regards,
>>> Kurt Mattes
>>> Senior Accessibility Consultant - Deque Systems
>>> 610-368-1539
>>>
>>>
>>>
>>
>


-- 
Regards,
Kurt Mattes
Senior Accessibility Consultant - Deque Systems
610-368-1539