RE: Understanding doc 1.4.11, updates

ALso agree with 1 and 2

About 3, functional / value states will be even more of a discussion point when for instance adding ARIA states / values, as these were recently extended.

See aria-current: https://www.w3.org/TR/wai-aria-1.1/#aria-current where the current state can contain more than one value e.g. true, page, step, location, date, time. Do these also need to be differentiated when used next to each other? Multiple aria-currents are possible although not recommended.


Regards,
Jake Abma

Accessibility Lead ING
Product owner at Team A11Y
http://www.a11yportal.com<http://www.a11yportal.com/>

ING Nederland / CIO / Omnichannel / Experience
ACT C.02.420, Bijlmerdreef 24
Postbus 1800, 1000 BV Amsterdam
0031 (0)6 - 25 27 52 46
jake.abma@ing.com



From: Michael Gower [mailto:michael.gower@ca.ibm.com]
Sent: donderdag 13 december 2018 19:20
To: Alastair Campbell <acampbell@nomensa.com>
Cc: WCAG <w3c-wai-gl@w3.org>
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<mailto:gowerm@ca.ibm.com>
cellular: (250) 661-0098 *  fax: (250) 220-8034



From:        Alastair Campbell <acampbell@nomensa.com<mailto:acampbell@nomensa.com>>
To:        WCAG <w3c-wai-gl@w3.org<mailto: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.


-----------------------------------------------------------------
ATTENTION:
The information in this e-mail is confidential and only meant for the intended recipient. If you are not the intended recipient, don't use or disclose it in any way. Please let the sender know and delete the message immediately.
-----------------------------------------------------------------