Re: CfC: Issue 157

it was LC-2893

> The Web Content Accessibility Guidelines Working Group has reviewed the
> comments you sent [1] on the Last Call Working Draft [2] of the
> Understanding WCAG 2.0 published on 16 Jan 2014.


On Thu, Apr 14, 2016 at 4:17 PM, David MacDonald <david100@sympatico.ca>
wrote:

> I'm  don't think it was "last call" as in "Last Call for review of WCAG
> before publication" but rather the "last phone call".
>
> It's all about a 2014 response to a question on list, rather than some
> earlier decision, associated closer with the standard...
>
> On Thu, Apr 14, 2016 at 4:33 PM, Gregg Vanderheiden RTF <
> gregg@raisingthefloor.org> wrote:
>
>> when the text said it was a comment on a last call — what was it a last
>> call on?
>>
>> if the quote was from a last call on WCAG - before it was issued - then
>> the quote was from 2008 (even if quoted in a 2014 email)
>>
>> was it a last call on WCAG?  or a last call on some document being
>> released in 2014?
>>
>> *gregg*
>>
>> On Apr 14, 2016, at 9:21 PM, Andrew Kirkpatrick <akirkpat@adobe.com>
>> wrote:
>>
>> To clarify, the response to Makoto was on a public review of updates to
>> the Understanding document in 2014, so it was not part of the 2008
>> discussions.
>>
>> The WG reviewed its past response with new arguments from the Low Vision
>> TF and decided that its decision was made with incomplete information and
>> felt that the interpretation needed to be reviewed as a result.
>>
>> This is all still non-normative guidance and reflects the bet thinking of
>> the WG at the time, and it is still possible that a site owner might decide
>> to interpret the SC differently – the only difference is that they would
>> not have the support of the WG’s most recent thinking to bolster their
>> argument if they take a different approach.
>>
>> 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 15:06
>> To: John Foliot <john.foliot@deque.com>
>> Cc: Andrew Kirkpatrick <akirkpat@adobe.com>, WCAG <w3c-wai-gl@w3.org>
>> Subject: Re: CfC: Issue 157
>>
>> Thank you John
>>
>> this is immensely helpful and thorough.
>>
>> I was just drafting a note back to Jonathan and the list — and was trying
>> to go dig up the history.   (I am in Germany in all day meetings this
>> week in prep for and presenting to the European Commission review team on
>> our Prosperity4All project — so was working off of the comment stream  -
>> since I didnt have time to research original text myself.)
>>
>> You are correct - I saw the comment about “the WG said” and thought that
>> was in the Understanding WCAG 2.0 document.    Since it was not - there is
>> no history of intent in that doc.
>>
>> However, if the comment you cite is from a Last Call response, it does
>> represent the thinking of the Working Group at the time  (which agrees with
>> my memory of the discussion at the time).     The WG specifically discussed
>> this and decided that it did NOT (and should not need to meet it in all
>> states.  There was a long discussion and debate about it at the time — but
>> the consensus was that it should not meet in all states (as noted below).
>> So it may not have been put into the Understanding WCAG 2.0 (which it
>> should have) but it is documented what the working group meant when it went
>> to final consensus vote.     So that is the meaning of the SC that was
>> passed by the WG.
>>
>> So - my conclusion still stands - though it would have been clearer if it
>> had been in the Understanding WCAG 2.0.    The responses to comments in
>> last call are however official public record of the meaning of the SC to
>> the WG at the time of passage.
>>
>> Note also the problem cited below with regard to the issue.  these were
>> some of the considerations we had at the time.
>>
>> *gregg*
>>
>> On Apr 14, 2016, at 8: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