Re: Focus appearance - history

Hi Jonathan,

I agree and I would also appreciate a focus visuals requirement which is more clearly focusing on consistency and supporting learned visual patterns. This would help providing a "continuum" as expressed in this mail thread.

The focus is, in general, a well established visual pattern in desktop and mobile operating systems, so it would be great if web applications would/could pick up these patterns and provide consistent visuals to expose the current focus position.

Secondly, I need to express my concern about the "one of two" pattern discussed. If you have two options and one option has focus and the other does not - it is still not clearly recognisable which option has focus, without interaction, if the focus is not rendered with consistent visual patterns: If focus is rendered inconsistently, e.g. one time it provides an outline outside the control, one time its rendering the outline inside, the user will not immediately be able to precisely judge which is the focused one.

In my opinion the focus should be recognisable without forcing the user to do anything, not moving a mouse, not using a keyboard key.
A recommendation conforming to the software usability standard ISO 9241-171 would also provide a consistent pattern for requirement definition:
ISO 9241-171 (Accessibility), paragraph 9.2.2. "Provide high visibility keyboard focus and text cursors" defines a requirement that a user can find a focus without need for interaction. If I remember correctly an old version also had the additional text "within one second".

I would greatly appreciate consistency for focus visuals on at least a set of web pages, better consistent to the OS environment.

Best regards, Oliver.


Oliver Keim
Accessibility Expert, Development Architect
SAP SE, Dietmar-Hopp-Allee 16, 69190 Walldorf, Germany

Pflichtangaben/Mandatory Disclosure Statement:
http://www.sap.com/company/legal/impressum.epx

Diese E-Mail kann Betriebs- oder Geschäftsgeheimnisse oder sonstige vertrauliche Informationen enthalten. Sollten Sie diese E-Mail irrtümlich erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts, eine Vervielfältigung oder Weitergabe der E-Mail ausdrücklich untersagt. Bitte benachrichtigen Sie uns und vernichten Sie die empfangene E-Mail. Vielen Dank.
This e-mail may contain trade secrets or privileged, undisclosed, or otherwise confidential information. If you have received this e-mail in error, you are hereby notified that any review, copying, or distribution of it is strictly prohibited. Please inform us immediately and destroy the original transmittal. Thank you for your cooperation.







On 22. Sep 2021, at 02:18, Jonathan Avila <jon.avila@levelaccess.com<mailto:jon.avila@levelaccess.com>> wrote:

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<mailto:acampbell@nomensa.com>>
Sent: Tuesday, September 21, 2021 5:48 PM
To: Gregg Vanderheiden <gregg@raisingthefloor.org<mailto:gregg@raisingthefloor.org>>
Cc: 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 - 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/>