Focus appearance - history

Hi Gregg,

As you were going to raise an issue on focus-appearance, I started writing a little history of the SC, and then figured it's useful for anyone that would like to take a crack at the SC text.

It started off as an update to focus visible, moving the current one to level A, and adding this:
https://docs.google.com/document/d/1g9_WBgfhViWAaRFIWWt10CP5rBsEVIWm3vT1vWqrHvI/edit#

NB: The user-need is for everyone using a keyboard (or equivelent) device, people with low-vision are a sub-set of that.

Whilst exploring the adjacency aspect (either/both) we worked through some test cases:
https://alastairc.uk/tests/wcag22-examples/focus-more-visible.html

Then tested these with members of the low-vision task force:
https://alastairc.uk/tests/wcag22-examples/focus-more-visible-2.html
(And the group reviewed various experiments after that, replace the "2" in the URL with 3-5.)
The main factors that seem to go into the visibility, from the testing and advice from an expert in vision, are:

  *   Surface area of the indicator, bigger is better.
  *   The contrast of that surface area is compared the un-focused state, more is better.
  *   The contrast of the surface area compared to it's adjacent colours, more is better.
Like many aspects of visual contrast, the user need is on a continuum, so the question is: Where to draw the line?

In some circumstances a single pixel, high-contrast line added around a link or button with no adjacent background is quite reasonable. The same line around a button with a background might be almost invisible. Thus the complication.

All the changes since the google-doc version are due to these (70) closed issues, many of which were dealing with different examples:
https://github.com/w3c/wcag/issues?q=is%3Aissue+is%3Aclosed+label%3A%222.4.11+Focus+appearance+%28min%29%22+

A lot of those issues are considering particular cases, e.g. circles, stars, short+thick side indicators, narrow components etc.

The other main suggestions have been:

  *   Don't allow for short & thick indicators, just mandate an outline approach (like the AAA version sort-of does) then it would be simpler, but that doesn't seem balanced in terms of allowing for some design approaches.
(From a google comment https://github.com/w3c/wcag/issues/1896)

  *   Use a simpler but less restrictive area metric, such as an area equivelent to 3 CSS pixels along the shortest edge. (https://github.com/w3c/wcag/issues/1718)
However, that then allows for some quite small indicators, well under the current requirement.

It is another one of those triangles: Complexity of SC text; meeting the user need; allowing for reasonable design approaches. Pick any two.

Kind regards,

-Alastair

--

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