Re: Updates to Understanding 1.4.11 part 2

On 13 Jun 2018, at 16:00, John Foliot wrote:

> Any Mac users familiar with this: https://www.focusingly.net ?

I’m familiar with it, the same effect can be archived really easily by 
using CSS instead of JavaScript:

```css
a, button, input, select, submit, textarea, 
[tabindex]:not([tabindex="-1"]) {
   outline: 2px solid transparent;
   outline-offset: 5px;
   transition: outline-offset .2s linear;
}

a:focus, button:focus, input:focus, select:focus, submit:focus, 
textarea:focus, [tabindex]:not([tabindex="-1"]):focus {
   outline-color: currentColor;
   outline-offset: 2px;
}
```

Demo: https://codepen.io/yatil/pen/EbjgRL

> I wonder aloud if it addresses the problem we're discussing (Mac's
> inaccessible native focus ring).

I personally find the “normal” Windows outline as hard to see than 
the Mac focus ring (especially on dark backgrounds) and I suggest 
specific styling whenever possible to take care of both operating 
systems.

Eric

>
> JF
>
> On Wed, Jun 13, 2018 at 8:50 AM, John Foliot <john.foliot@deque.com> 
> wrote:
>
>> David's bug thread also provides the current 'status':
>>
>> michael-n-cooper <https://github.com/michael-n-cooper> commented on 
>> Sep
>> 28, 2017 
>> <https://github.com/w3c/wcag21/issues/298#issuecomment-332865121>
>>
>> This is out of scope for WCAG 2.1, but we will look at this sort of 
>> issue
>> again in Silver.
>>
>>
>> To my mind there are differences between technical compliance and
>> "practical" compliance, and while it is true that you can wiggle you 
>> way
>> out of the Mac problem using a technical reading of WCAG (David's 
>> point), I
>> suspect that for most designers (who are likely using Macs anyway) 
>> that we
>> should teach them the 'optimum' and down-play the minimum (i.e., be
>> pragmatic, fix the problem on the Mac platform - Alastair's point).
>>
>> I think framed right, designers are going to want to do this right 
>> anyway
>> (most designers I've met want to control all aspects of the design, 
>> on all
>> platforms), and we can re-enforce the idea that different platforms 
>> have
>> different focus indicators in the Understanding document, and that
>> designers *should* carefully consider this fact when creating new
>> designs/focus indications.
>>
>> JF
>>
>>
>> On Wed, Jun 13, 2018 at 8:28 AM, David MacDonald 
>> <david100@sympatico.ca>
>> wrote:
>>
>>>> I’m a little confused in what you mean, the technologies relied 
>>>> on in
>>> this case would be HTML, CSS etc.
>>>
>>> The technology relied upon in WCAG is the tools that users are 
>>> expected
>>> to use to get the benefits of the WCAG conformance. There is no 
>>> obligation
>>> to make things work in every browser with every screen reader and 
>>> AT...
>>> There just has to be on stack of technology i.e. Windows, Firefox, 
>>> NVDA.
>>> We're not talking a about HTML/CSS here we are talking about the
>>> expectations for a user. One must remember that for most of WCAG 
>>> Apple was
>>> a non starter. There was no assistive technology and no initiative 
>>> by apple
>>> to do anything about that, and back then is was basically JAWS, 
>>> Windows and
>>> IE ... so of course we couldn't say that so Conformance requires 
>>> just one
>>> combination of user technologies work. If we change that in WCAG 2.1 
>>> (and
>>> we haven't) we are talking about a completely different set of 
>>> requirements
>>> than WCAG 2.0 in 2.1.
>>>
>>> This stuff is important.
>>>
>>>> I’m probably biased by the UK/EU context where these things are
>>> generally interpreted in fairly practical ways, it would be odd to 
>>> exclude
>>> a popular browser or platform and claim that it works.
>>>
>>> Hmmm.... when was the last lawsuit that had any effect in the UK?
>>>
>>> We simply cannot require content to work on all or many 
>>> combinations. I
>>> raised an issue to explore that an the WG decided to stick with WCAG 
>>> 2.0
>>> conformance requirements.
>>>
>>> https://github.com/w3c/wcag21/issues/298
>>>
>>> This is critical, and I simply won't be able to provide consensus to 
>>> this
>>> interpretation without a wider discussion of its implications. It is 
>>> at
>>> odds with our own documentation for 2.1.
>>>
>>> Cheers,
>>> David MacDonald
>>>
>>>
>>>
>>> *Can**Adapt* *Solutions Inc.*
>>>
>>> Tel:  613.235.4902
>>>
>>> LinkedIn
>>> <http://www.linkedin.com/in/davidmacdonald100>
>>>
>>> twitter.com/davidmacd
>>>
>>> GitHub <https://github.com/DavidMacDonald>
>>>
>>> www.Can-Adapt.com <http://www.can-adapt.com/>
>>>
>>>
>>>
>>> *  Adapting the web to all users*
>>> *            Including those with disabilities*
>>>
>>> If you are not the intended recipient, please review our privacy 
>>> policy
>>> <http://www.davidmacd.com/disclaimer.html>
>>>
>>> On Wed, Jun 13, 2018 at 8:34 AM, Alastair Campbell 
>>> <acampbell@nomensa.com
>>>> wrote:
>>>
>>>> Hi David,
>>>>
>>>>
>>>>
>>>> Thanks for looking through, on your points:
>>>>
>>>>
>>>>
>>>>> The #1 statement has 2 bullets. Is the proposal that these are an 
>>>>> AND
>>>> statement or and OR statement, we need that explicit, its a big 
>>>> difference.
>>>>
>>>>
>>>>
>>>> It is an and/or, i.e. you could use any combination of text, 
>>>> graphical
>>>> content, background/border etc.
>>>>
>>>>
>>>>
>>>> If you look at the first assumption, I put:
>>>>
>>>> For "Visual information required to identify user interface 
>>>> components
>>>> and states", it is flexible as to what the indicator(s) is/are, the 
>>>> author
>>>> can decide. However, if the indicator is "required to identify" the
>>>> component, then it must have contrast. The main differences are 
>>>> that:
>>>>
>>>>    - Buttons and links can be identified simply by text;
>>>>    - For controls which are more interactive (e.g. checkboxes / 
>>>> radio
>>>>    buttons) that would require more than text.
>>>>
>>>>
>>>>
>>>> Perhaps that first step needs splitting up to distinguish the types 
>>>> of
>>>> control, and incorporate that assumption?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> For the last #4 item... this will be an undue burden to test and
>>>> remediate, with disproportionally few benefits to the end user ... 
>>>> WCAG has
>>>> not traditionally wandered beyond the default and focused state, 
>>>> these are
>>>> split second states.
>>>>
>>>> …
>>>>
>>>>> Instead, I think we should say that momentary transient states are
>>>> not visible/noticeable to many people and therefore out of scope.
>>>>
>>>>
>>>>
>>>> I’m not sure how to square that with the SC text & definition of 
>>>> states,
>>>> we’ve already been through that conversation with hover.
>>>>
>>>>
>>>>
>>>> However, the mitigations are that:
>>>>
>>>>    - A change of pointer can count as an indicator (for hover);
>>>>    - If a control doesn’t visually change for a particular state, 
>>>> it is
>>>>    not required to (because there is no visual information).
>>>>    - Most components don’t have that many states.
>>>>
>>>>
>>>>
>>>> In the examples most of that failed did so due to default 
>>>> indicators or
>>>> focus state, not the other states.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> On the call I mentioned that Technologies relied upon for 
>>>>> conformance
>>>> is a critical consideration when failing/passing default states. If 
>>>> Safari
>>>> is not relied upon for conformance, then it is not a failure of 
>>>> WCAG that
>>>> it's focus ring doesn't pass. If there is a stack that works, it 
>>>> passes.
>>>>
>>>> https://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html
>>>>
>>>>
>>>>
>>>> I’m a little confused in what you mean, the technologies relied 
>>>> on in
>>>> this case would be HTML, CSS etc. There is also the aspect of what 
>>>> you
>>>> claim to have tested on, in the ‘Optional components of a 
>>>> conformance
>>>> claim’, but I’m not sure what you’d interpret as “If there 
>>>> is a stack
>>>> that works, it passes”?
>>>>
>>>>
>>>>
>>>> I’m probably biased by the UK/EU context where these things are
>>>> generally interpreted in fairly practical ways, it would be odd to 
>>>> exclude
>>>> a popular browser or platform and claim that it works.
>>>>
>>>>
>>>>
>>>> -Alastair
>>>>
>>>
>>>
>>
>>
>> --
>> 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





--

Eric Eggert
Web Accessibility Specialist
Web Accessibility Initiative (WAI) at World Wide Web Consortium (W3C)