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.