Re: Understanding doc 1.4.11, updates

I wanted to flag mild concerns I have with the third example in the User 
of Color and Focus Visible section.

The alt text is "Two buttons, one with a dark background and no border. 
The second has a light coloured border applied within the boundary of the 
button"

I guess I can buy the argument that the button's shape is REDUCED in size 
by deducting a noticeable amount of black color from the exterior. But 
when considering ONLY the focus outline, the outline is not 3:1 with the 
adjacent white background.

Put in a more bald way, if that outer edge was changed to white -- in 
other words, it is ENTIRELY a change of shape and there is no visible 
indicator "added" (for anyone) -- would it still be okay? I get a little 
queasy thinking that a user is going to need to depend on either 
remembering the relative size of the buttons to understand something in 
the viewport has focus OR will need to see two buttons in the viewport to 
decide which one has focus and understand that it is the smaller one that 
indicates focus. It's a little counter intuitive. Obviously, David's 
campaign of a double line with contrasting colours would be the BEST 
implementation of this, IMO. In the example I've done below, the black 
outer line has a clear contrast with the white background of the page as 
well as with the white inner boundary of the button. 



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:   "Michael Gower" <michael.gower@ca.ibm.com>
To:     Alastair Campbell <acampbell@nomensa.com>
Cc:     WCAG <w3c-wai-gl@w3.org>
Date:   2018-12-13 10:21 AM
Subject:        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.