W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > April to June 2018

Re: SC 1.4.11

From: John Foliot <john.foliot@deque.com>
Date: Fri, 22 Jun 2018 17:38:11 -0500
Message-ID: <CAKdCpxz617Z=9h5aQD317xGCKmnzdohgvBPn2cxjbJarYFuHpw@mail.gmail.com>
To: Laura Carlson <laura.lee.carlson@gmail.com>
Cc: WCAG <w3c-wai-gl@w3.org>
Alastair, apologies for the fat fingers in my last post - I kinda mangled
your name unintentionally. Sorry brother.


On Fri, Jun 22, 2018 at 5:32 PM, John Foliot <john.foliot@deque.com> wrote:

> Hey Alastyair
> > Firstly, I still read the state as something that is ‘of’ a component.
> Yup, and this seems to be the key stumbling block
> ​ as you and I do not see the same thing​.
> I will continue to fall back on something *you* said just recently - "
> *we added states to say that it applies to states as well*
> ​" - as this (to me) clearly signals that when the Working Group added
> this text​, we did so because "states" as part of a component was
> previously ambiguous or undefined. I agree, and agree with the addition of
> that additional qualifier.
> But since we had to qualify that in the requirement statement, *but
> didn't in the exception statement*, the case CAN be made that this was
> deliberate, and that we intended for the precise reading (and frankly, that
> was always my read of this). People like Wilco and Eric have publicly
> agreed with that perception/understanding in this thread, and I have heard
> from one or two others off-list who want to agree, but remained concerned
> about this ambiguity and the impact on legal readings of the normative
> text. I can appreciate that, and if nothing this conversation has simply
> solidified the fact that we DO need to disambiguate this in our
> Understanding document.
> Let me pose this final question: outside of the potential impact this
> disambiguation would bring (if we accepted the strict reading), are there
> any downsides in the bigger picture?
> I get that there will likely be many sites who will be stuck TODAY because
> they "assumed" that the native default focus indication was sufficient
> (even though we now know this to be false), but I ask in all seriousness,
> how different is this from sites that previously "assumed" that CSS resets
> that removed *outline *were also OK, or previously assumed that *.headline
> {font-size:300%; color: orange;}* was also OK? There are no shortage of
> bad decisions on the web today, and I don't think coddling uninformed or
> misinformed page authors is the right way forward (but that's me).
> Any existing problems on the web today, directly related to this issue
> (contrast of the visible tab focus), are going to most likely be author
> error anyway, and since 2.1 has no legal impact today, let's get this
> problem cleaned up quickly, and start teaching the right thing now (and not
> down the road in 2.2 when some suggest we can revisit and get wider, or
> narrower, or whatever). I say, use the strict reading, explain the strict
> reading, and let's get out there and make the web more accessible.
> Finally,
> let's not forget we already have a Success Technique that addresses this
> very concern (in the context of SC
> <http://www.w3.org/TR/2008/REC-WCAG20-20081211/#navigation-mechanisms-focus-visible>
> 2.4.7 (Focus Visible)
> <http://www.w3.org/TR/2008/REC-WCAG20-20081211/#navigation-mechanisms-focus-visible>
> ):
> https://www.w3.org/TR/WCAG20-TECHS/G195.html
> I will further argue that we can point to that pre-existing Technique as
> "proof" of our intent going forward. (And yes, there is another Technique:
> *G149: Using user interface components that are highlighted by the user
> agent when they receive focus*
> *​* that suggests that native focus indicators might do*​, *but it has a
> very critical qualifier: "
> *UAAG-conformant user agents* do so when they satisfy checkpoint 10.2
> "Highlight selection, content focus, enabled elements, visited links".
> ​) So, since it seems that neither Chrome nor Safari today are meeting
> this UAAG SC, authors cannot rely on this Technique​ to meet *either* SC
> 2.4.7 NOR 1.4.11 (and as an mechanism to get around the ambiguity, we
> *might* want to use this or similar language in the Understanding doc for
> 1.4.11) Not ideal, but a potential path forward.
> Have a great weekend as well friend.
> JF
> On Fri, Jun 22, 2018 at 4:19 PM, Laura Carlson <
> laura.lee.carlson@gmail.com> wrote:
>> Hi John,
>> On 6/20/18, John Foliot <john.foliot@deque.com> wrote:
>> > Should this Working Group not also adopt the Priority
>> > of Constituents used in HTML5: users over authors, authors over
>> > implementors, implementors over code purity?
>> Ah yes. That certainly brings back memories :-)
>> However, that probably should have been brought up at the start of 2.1.
>> Other models were surfaced then. Check David's Venn Diagram:
>> http://www.davidmacd.com/blog/what-are-WCAG-success-criteria.html
>> Maybe a discussion for 2.2?
>> Kindest Regards,
>> Laura
>> --
>> Laura L. Carlson
> --
> John Foliot
> Principal Accessibility Strategist
> Deque Systems Inc.
> john.foliot@deque.com
> Advancing the mission of digital accessibility and inclusion

John Foliot
Principal Accessibility Strategist
Deque Systems Inc.

Advancing the mission of digital accessibility and inclusion
Received on Friday, 22 June 2018 22:38:35 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 21:08:26 UTC