Re: Updates to Understanding 1.4.11 part 2

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