Re: CfC: Issue 157

Hi Gregg,

I believe the response was to the January 2014 Editors Draft of
"Understanding" (
https://www.w3.org/WAI/GL/2014/WD-UNDERSTANDING-WCAG20-20140107/), as
referenced in the archived response:
https://lists.w3.org/Archives/Public/public-comments-wcag20/2014Feb/0039.html

Sadly, I don't see the opinion referenced elsewhere, which is a gap (stuff
happens).

JF

On Thu, Apr 14, 2016 at 3: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