RE: Focus appearance - history

I would also add that many of the valid concerns raised by Gregg are things that have been discussed.  For example, when you are in a zoomed in or magnified viewport having another interactive control to compare against may not exist.  This not only applies to changes in button size but also to other techniques such as simply swapping the background/foreground colors of buttons which is a common technique to show focus indication.  Such a technique is very much a challenge to users who are left wondering which button is the focused one and which is not focused - but any solution would impose a standard type of indicator and the ability to get consensus on that was and remains a challenge.  Focus indicators continue to encompass a wide range of implementations including ones where the colors simply darker to ones where underlines appear - often making the item simply look like a link.   The new criteria address some of these implementations and while they don't address all situations they greatly improve the situation without allowing an out via user agent default.

The Low Vision Task Force is planning to work on supplemental guidance that may be provided as informative guidance where we can provide additional recommendations for user needs that were not able to be turned into WCAG 2.2 criteria.  Providing more standard type indicators such as one that can be identified when only one or two controls are present would be a useful guidance addition.  Some of the techniques we have today such as a double focus indicator with a black rectangle and a white rectangle are techniques that we can point to as practices that increase access.  We welcome any additional recommendations and your review of guidance.

Jonathan

From: Alastair Campbell <acampbell@nomensa.com>
Sent: Tuesday, September 21, 2021 5:48 PM
To: Gregg Vanderheiden <gregg@raisingthefloor.org>
Cc: WCAG list (w3c-wai-gl@w3.org) <w3c-wai-gl@w3.org>
Subject: Focus appearance - history

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

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#<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>