Re: Updates to Understanding 1.4.11 part 2

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

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

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