Re: Updates to Understanding 1.4.11 part 2

> 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
>