Re: CfC: Issue 157

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