W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > January to March 2022

RE: Focus appearance updates

From: Suzanne Taylor <suzanne.taylor@thingsentertainment.net>
Date: Wed, 9 Mar 2022 14:50:31 +0000
To: Alastair Campbell <acampbell@nomensa.com>, WCAG list (w3c-wai-gl@w3.org) <w3c-wai-gl@w3.org>
Message-ID: <0100017f6f28fac9-663b2398-6c0d-415c-a8be-3cda8a61df40-000000@email.amazonses.com>

Thanks so much for noticing and attending to my comment. I think the more we can prevent people from having to process the exception, the better.

Current proposal from this email: “Continuously surrounds, bounds or includes the whole of, except for decorative effects such as shadows”

I would replace “decorative” with “external,” because even the internal rounded edges of a button could be interpreted to be decorative.

New proposal: “Continuously surrounds, bounds or includes the whole of, except for external effects such as shadows”

External reflections,  glows, and shadows can be very faint and even invisible to many in the target audience for this guideline. Their far edges might be far away from the UIC and may even overlap each other or be under other components.

From: Alastair Campbell <acampbell@nomensa.com <mailto:acampbell@nomensa.com> > 
Sent: Wednesday, March 09, 2022 5:55 AM
To: WCAG list (w3c-wai-gl@w3.org <mailto:w3c-wai-gl@w3.org> ) <w3c-wai-gl@w3.org <mailto:w3c-wai-gl@w3.org> >
Subject: Focus appearance updates

Hi everyone,

To follow up on yesterday’s meeting I’d like to summarise the changes and comments/responses. These are all in the doc:

https://docs.google.com/document/d/1TI_DsJjfg9RW_A9C1XfqgtfYqNMfnxeCz6lxjpOQ9rk/edit# <https://docs.google.com/document/d/1TI_DsJjfg9RW_A9C1XfqgtfYqNMfnxeCz6lxjpOQ9rk/edit> 

I’m just adding this email for the record and so people notice.

To summarise the changes since the previous version:

*	The first part of the SC is much simpler, but a slightly higher bar than the previous version. I.e. a continuous line around (or bounding) the component with contrast for the change and adjacency. That disqualifies dotted/dashed lines, or indicators which include non-contrasting shadows/gradients.
*	The second part of the SC includes two exceptions for user-agents.
*	The second part of the SC includes an exception with the same language for sizing (based on area) as the previous one. It uses the of 4px along shortest side version of that.

From the logic/math of the SC anything that passes the previous version should pass this version due to the size exception. The one oddity is: Circles (or very rounded squares) with a 1px contrasting outline. Where the shortest side = longest side, the maths means the perimeter doesn’t meet the area and it would need to be thicker.

We could allow for that case by incorporating the 1px permitter language from the previous version, but that adds complexity to reading / understanding the SC. 

Apart from that oddity, any dashed/dotted/decorative examples that passed before should pass now based on the sizing language in the exception.


Going in order of the SC text (and comments in the doc):

*	Gundula / Wilco wondered about dotted / dashed lines which could pass depending on how you interpret “encompasses”. 
My suggestion is to update the definition of “Encompasses” to say:
“Continuously surrounds, bounds or includes the whole of” 
*	Wilco was concerned about how we determine the size based on User Interface Controls (UIC). 
We've been through many (all?) the alternatives, if you look through the UIC section in the doc it outlines a way it could be documented in the understanding doc (although it is written for the group at the moment).

A key factor is that you can use the focus indicator to work out what the UIC is. Anything passing 2.4.7 must have a focus indicator, therefore the location of that indicator can help you work out what the UIC is. That is very helpful in the Card & sub-component examples.

Also, we can include all the decorative aspects like drop-shadows and if it does not meet the first part, it is very likely to pass the size exception.
*	AndrewK thought we should remove the adjacent contrast aspect as it is covered in non-text contrast. Unfortunately, it isn’t in some key cases, see this example: https://w3c.github.io/wcag/understanding/non-text-contrast.html#figure-focus-outer-green <https://w3c.github.io/wcag/understanding/non-text-contrast.html#figure-focus-outer-green> 
*	Jon & MichaelG wondered about “indicator’s background” in the exception. For some components, the focus indicator goes inside the component. What matters is the change of contrast, and that can be in or out of the component. That is why is say the background of the indicator.
*	Gundula and Wilco asked about decorative effects. 
If you look at the shadow examples, unless it is a square or circle (i.e. the shortest side = longest side) then the area of a solid indicator would be more than 4px * length. 
It would need to be 2px or thicker, but it keeps it simpler.
I wonder if we can drop the 2px thickness requirement in this configuration? With the emphasis on standard & contrasting outlines, it doesn’t matter as much.
The other option is to re-integrate the 1px perimeter area option again as part of the size exception.
*	Jon wanted to add a note about sub-components, which is related to the UIC issue. I’ve added this to the document:
“NOTE: Where a component has sub-components (e.g. a drop-down menu), the focused item is the scope of this success criterion.”
*	Suzanne thought that decorative effects should be ignored for the purpose of the SC.
Most should pass via the exception, however, that is another possibility. We could potentially build that into the definition of encompasses, e.g.:
“Continuously surrounds, bounds or includes the whole of, except for decorative effects such as shadows”

If you have any comments or follow-up on that please reply/comment soon, I’d like to get a series of smaller decisions ready for next week.

Kind regards,



@alastc / www.nomensa.com <http://www.nomensa.com> 

Received on Wednesday, 9 March 2022 14:51:26 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 21:08:43 UTC