Re: CfC: Issue 157

(My apologies to Makoto for mis-spelling his name, it should read: Makoto
Ueki. Sorry friend)

JF

On Thu, Apr 14, 2016 at 1:54 PM, John Foliot <john.foliot@deque.com> wrote:

> Hi Gregg,
>
> I think, as I review the WCAG Success Criteria, that one of the key issues
> is that the Recommendation does not speak specifically to this issue - that
> in fact there is a vacuum here that needs filling.
>
> Success Criteria 1.4.3 Contrast (Minimum) states*:* The visual
> presentation of text <https://www.w3.org/TR/WCAG20/#textdef> and images
> of text <https://www.w3.org/TR/WCAG20/#images-of-textdef> has a contrast
> ratio <https://www.w3.org/TR/WCAG20/#contrast-ratiodef> of at least 4.5:1,
> except for the following: (Level AA)
>
>    -
>
>    Large Text: Large-scale <https://www.w3.org/TR/WCAG20/#larger-scaledef> text
>    and images of large-scale text have a contrast ratio of at least 3:1;
>    -
>
>    Incidental: Text or images of text that are part of an inactive user
>    interface component
>    <https://www.w3.org/TR/WCAG20/#user-interface-componentdef>, that are pure
>    decoration <https://www.w3.org/TR/WCAG20/#puredecdef>, that are not
>    visible to anyone, or that are part of a picture that contains significant
>    other visual content, have no contrast requirement.
>    -
>
>    Logotypes: Text that is part of a logo or brand name has no minimum
>    contrast requirement.
>
>
> ​Absent here is the notion of "state" - the SC neither explicitly includes
> or precludes the idea that "text", and the color of the text, can change
> dependant on state (visited, unvisited, active, onHover/onMouseover, etc.).
> Whether this was by conscious design, or an error of omission I do not
> know, but a strict reading of the SC clearly does not explicitly address
> that concern.
>
>
> I will note that on the call, Makoto Ukei brought forward earlier
> "guidance"
> <https://lists.w3.org/Archives/Public/public-comments-wcag20/2014Feb/0039.html>
> regarding this gap based upon a Last Call comment, and he noted that
> previously the WG did suggest otherwise ("
> The opinion of the working group is that the color-contrast ratio of the
> link text when focused or hovered does not need to meet 1.4.3/1.4.6. The
> goal of the color contrast success criteria is to ensure that content can
> be read by users, so as long as the links are sufficient contrast when not
> focused/hovered then they will meet 1.4.3/1.4.6.
> ​")
>
> HOWEVER I also note that this opinion was never incorporated into the
> Normative Requirements​ (and that finding the opinion/decision would likely
> be onerous to those not familiar with the ins-and-outs of W3C archiving :)
> ) Further, there is no mention of this opinion/decision in the
> Understanding documentation for either SC1.4.3 nor SC1.4.6
>
> I agree that sites that may have operated under the earlier opinion would
> be impacted here from an 'intent' perspective, but as the Success Criteria
> does not speak directly to the question of state, it remains, effectively,
> an unresolved question.
>
> I would suggest that the best way forward would be to ensure that the
> decision (as well as the prior decision) be captured in the Understanding
> documentation, with a note that content created prior to the opinion not be
> held accountable to the opinion in terms of success or failure - yes, that
> feels squishy, but I cannot think of another way out: officially the SC
> says nothing.
>
> Thoughts?
>
> JF
>
> On Thu, Apr 14, 2016 at 1:30 PM, Gregg Vanderheiden RTF <
> gregg@raisingthefloor.org> wrote:
>
>> Sorry
>>
>> I was thinking 12:45 was at night.
>>
>> My comment still stands.  I don’t think it is within the purview of the
>> WG to do this — to normatively re-interpret something to be covered that
>> the WG at the time said was not.
>>
>> *gregg*
>>
>> On Apr 14, 2016, at 8:22 PM, Andrew Kirkpatrick <akirkpat@adobe.com>
>> wrote:
>>
>> Gregg,
>> The deadline is passed, not sure where you are seeing otherwise.
>>
>> We discussed this at length and did not feel that this interpretation to
>> be out of line with what the WG believed at the time the SC were
>> finalized.  Can you clarify specifically how you feel that this is
>> incorrect?
>>
>> Thanks,
>> AWK
>>
>> Andrew Kirkpatrick
>> Group Product Manager, Accessibility and Standards
>> Adobe
>>
>> akirkpat@adobe.com
>> http://twitter.com/awkawk
>>
>> From: CAE-Vanderhe <gregg@raisingthefloor.org>
>> Date: Thursday, April 14, 2016 at 14:11
>> To: Andrew Kirkpatrick <akirkpat@adobe.com>
>> Cc: WCAG <w3c-wai-gl@w3.org>
>> Subject: Re: CfC: Issue 157
>>
>> Hi All,
>>
>> it is still before the deadline - but I see this item was called.
>>
>>
>>
>> l will post my concern anyway.
>>
>>
>> I am sorry to have to say - but I disagree with this answer / response.
>>
>> It is my understanding — (and a general operating principle in standards)
>>  that the Working group cannot change the interpretation of a standard
>> after the issuing of the standard.   The understanding at the time the
>> standard was passed,  and the understanding released publicly and on which
>> the public interpreted and commented on the standard,  and the
>> interpretation of the working group when it reached consensus on the
>> provision must prevail.
>>
>> From the discussion - it appears that it is the understanding that the
>> Working Group meant it to mean one thing — and the new Working Group is
>> deciding to change the meaning.    This would constitute a
>> re-interpretation of the standard — in a normative way — after adoption.
>>
>>
>> The interpretation of the standard at the time it was passed must stand
>> as long as the provision stands.
>>
>> Changing the interpretation - when it was clearly stated - is equivalent
>> to normatively changing the standard after the fact.
>>
>>
>> The working group should always strive to interpret the standard * as
>> they believe the working group understood the standard at the time
>> consensus was reached by the working group.*
>>
>> This is independent of whether this is a good idea or not.
>>
>> ————————————————
>>
>> Now separate from that - -one should keep in mind - that this
>> interpretation also conflicts with the conformance criteria which allow
>> things to take different forms and only need to meet the guidelines in one
>> form.   For example a page can have one viewing option that is does not
>> meet the success criteria as long as there is another viewing option that
>> does.
>>
>>
>> Finally,  due to the math - you cannot have two colors that both meet the
>> SC at 7 and are still appreciably different from each other in contrast
>> with the page.
>>
>>
>>
>> I think that for future work (revisions) both of these issues should be
>> taken into account before deciding.  They were among the reasons the
>> Working Group decided as it did last time.
>>
>> However, with respect to WCAG 2.,  both of these latter are irrelevant if
>> the group really believes that the WG meant it one way — and they are
>> deciding to differ and are redefining the normative term (or its
>> interpretation) after the fact.    That is not really really appropriate to
>> do without issuing a new standard because it is in effect making a
>> normative change to a standing standard.
>>
>>
>>
>> If I misunderstood something — let me know.   (or if you disagree - I am
>> happy to discuss whether I am right.) but I THINK that this is outside of
>> the WG purview for the reasons above.
>>
>> respectfully
>>
>> *gregg*
>>
>> On Apr 12, 2016, at 6:43 PM, Andrew Kirkpatrick <akirkpat@adobe.com>
>> wrote:
>>
>> CALL FOR CONSENSUS – ends Thursday April 14 at 12:45pm Boston time.
>>
>> GitHub issue 157 related to the need for the focus and hover states to
>> meet WCAG contrast requirements was discussed on the April 12 WCAG
>> teleconference and surveyed to the group (
>> https://www.w3.org/2002/09/wbs/35422/5April2016_misc/results#xi157).
>>
>> Proposed response:
>> https://github.com/w3c/wcag/issues/157#issuecomment-208996348
>>
>> If you have concerns about this proposed consensus position that have not
>> been discussed already and feel that those concerns result in you “not
>> being able to live with” this position, please let the group know before
>> the CfC deadline.
>>
>> Thanks,
>> AWK
>>
>> Andrew Kirkpatrick
>> Group Product Manager, Accessibility and Standards
>> Adobe
>>
>> akirkpat@adobe.com
>> http://twitter.com/awkawk
>>
>>
>>
>>
>
>
> --
> John Foliot
> Principal Accessibility Consultant
> Deque Systems Inc.
> john.foliot@deque.com
>
> Advancing the mission of digital accessibility and inclusion
>



-- 
John Foliot
Principal Accessibility Consultant
Deque Systems Inc.
john.foliot@deque.com

Advancing the mission of digital accessibility and inclusion