Re: Understanding doc 1.4.11, updates

Agree on 1. boundaries

> 2. States do not have to be differentiated within the component, e.g. 
hover is not required to be contrasting with non-hover.

Agree, given the language. I still believe we can set up 2.1 toward a 3:1 
contrast for "visible" focus indicator differentiation by making a good 
2.4.7/1.4.11 combo technique, even if we can't get agreement that we can 
do a failure technique.

> 3. Functional / value states do require differentiation via ‘adjacent’ 
background. 

I do not think we will can consensus that this is currently covered in 
2.1, as per the current language. I think defining which states for what 
kinds of controls need to differentiate, and to what degree, is an 
interesting candidate for 2.2, and there's nothing stopping us from having 
those guidelins developed NOW has advisory techniques for 1.4.11


Michael Gower
Senior Consultant
IBM Accessibility
Research

1803 Douglas Street, Victoria, BC  V8T 5C3
gowerm@ca.ibm.com
cellular: (250) 661-0098 *  fax: (250) 220-8034



From:   Alastair Campbell <acampbell@nomensa.com>
To:     WCAG <w3c-wai-gl@w3.org>
Date:   2018-12-12 01:41 AM
Subject:        Understanding doc 1.4.11, updates



Hi everyone,

I thought it might help to highlight some of the key decision points for 
the understanding doc updates [1] on non-text contrast. I’m not pushing 
for one way or another in this email, just presenting my understanding of 
the choices and whether they have been explicitly decided before.

These are all for the 1st bullet point on User Interface Components.

1. Boundaries are not required on links & buttons, or hit areas in 
general. Therefore contrast for those boundaries is not required either. 
This was thought ok because (given some button styles don’t use 
borders/backgrounds) they are not required to visually identify the 
components.

That was decided in the run-up to the 2.1 publication.

2. States do not have to be differentiated within the component, e.g. 
hover is not required to be contrasting with non-hover. From the SC text 
each state must provide contrast with it’s souroundings, but not 
necessarily with itself in other states.
When related to Focus Visible, contrast is added as a possible method via 
1.4.11, and ‘visible’ is better defined.

This was discussed previously [2] and at the time it was proposed that 
hover didn’t need to be differentiated due to other information being 
available, e.g. the pointer location.

However, I don’t think that works as an overall method of saying that 
certain states don’t need contrast because:
- Buttons don’t (by default or according to the CSS spec) change the 
pointer on hover.
- What about visited links? A link can be default, visited, hovered, 
focused, and any combination of those things. We can’t require those 
states are differentiated where they are not already. If we try, I think 
people will remove subtle hints for those ‘niche’ states rather than try 
to make them contrast, and I wouldn’t blame them as it’s impossible to do.
- These link states are programmatically available, there’s a good case 
that if that’s a need, it can be provided by user agents, e.g. 
user-created CSS.


3. Functional / value states do require differentiation via ‘adjacent’ 
background. 
For checkboxes, radio buttons, multi-selects, and selected tabs provide 
functional state information and have the possibility to have ‘adjacent’ 
colours, whereas that is not necessarily the case for links/buttons.

This is the trickier one, and depending on your reading of the SC text 
might be incompatible with decision 2 if that is decided in favour of not 
differentiating states. 

I don’t think this has been discussed (as people have assumed it is 
covered), however, if we go with decision 2 and decide this is 
incompatible, 3 becomes a strong contender as an addition for a WCAG 2.2. 
Detlev emailed the list about a way of doing that.

Have a read of the understanding doc [1], most of the changes are to cover 
new methods of meeting Focus Visible, but the above are key decisions.

-Alastair


1] https://github.com/w3c/wcag/pull/550

2] https://github.com/w3c/wcag/issues/400#issuecomment-401413694





Apologies for typos, sent from a mobile.