Re: Updates to Understanding 1.4.11 part 2

John Foliot wrote:
> Any Mac users familiar with this: https://www.focusingly.net ?
Thanks for that John, useful.

Josh
>
> 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 
> <mailto: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 <mailto: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
>         <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 <http://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 <mailto: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 <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 <mailto:john.foliot@deque.com>
>
>     Advancing the mission of digital accessibility and inclusion
>
>
>
>
> -- 
> John Foliot
> Principal Accessibility Strategist
> Deque Systems Inc.
> john.foliot@deque.com <mailto:john.foliot@deque.com>
>
> Advancing the mission of digital accessibility and inclusion


-- 
Joshue O Connor
Director | InterAccess.ie

Received on Wednesday, 13 June 2018 16:42:07 UTC