Re: CfC: Issue 157

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 <mailto: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 <mailto:akirkpat@adobe.com>
> http://twitter.com/awkawk <http://twitter.com/awkawk>
> 
> From: CAE-Vanderhe <gregg@raisingthefloor.org <mailto:gregg@raisingthefloor.org>>
> Date: Thursday, April 14, 2016 at 15:06
> To: John Foliot <john.foliot@deque.com <mailto:john.foliot@deque.com>>
> Cc: Andrew Kirkpatrick <akirkpat@adobe.com <mailto:akirkpat@adobe.com>>, WCAG <w3c-wai-gl@w3.org <mailto: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 <mailto: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. <http://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. <http://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 <mailto: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 <mailto: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 <mailto:akirkpat@adobe.com>
>>>> http://twitter.com/awkawk <http://twitter.com/awkawk>
>>>> 
>>>> From: CAE-Vanderhe <gregg@raisingthefloor.org <mailto:gregg@raisingthefloor.org>>
>>>> Date: Thursday, April 14, 2016 at 14:11
>>>> To: Andrew Kirkpatrick <akirkpat@adobe.com <mailto:akirkpat@adobe.com>>
>>>> Cc: WCAG <w3c-wai-gl@w3.org <mailto: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 <mailto: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 <https://www.w3.org/2002/09/wbs/35422/5April2016_misc/results#xi157>).
>>>>> 
>>>>> Proposed response:
>>>>> https://github.com/w3c/wcag/issues/157#issuecomment-208996348 <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 <mailto:akirkpat@adobe.com>
>>>>> http://twitter.com/awkawk <http://twitter.com/awkawk>
>>> 
>> 
>> 
>> 
>> -- 
>> John Foliot
>> Principal Accessibility Consultant
>> Deque Systems Inc.
>> john.foliot@deque.com <mailto:john.foliot@deque.com>
>> 
>> Advancing the mission of digital accessibility and inclusion
>