Re: SC 1.4.11

Alastair, apologies for the fat fingers in my last post - I kinda mangled
your name unintentionally. Sorry brother.

JF

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.
john.foliot@deque.com

Advancing the mission of digital accessibility and inclusion