RE: CFC - WCAG 2.2 Focus Appearance, Normative Text

Given this -1 contains a substantial argument against the SC, I would like to counter.


  *   Knowing the exact size, shape, and position of a component is essential when applying this success criterion.


That’s not true. If an author simply uses a focus outline on a well-defined component, no one need worry about the size or the shape of the component, or the area portion. The most common and arguably most effective focus indicator – an offset contrasting focus rectangle – clearly passes every time.
After trials, assessment was applied to the focus indicator itself, rather than the component (since the component measure was problematic, as you know). This made it much simpler to assess, because it is easy to tell which pixels form the focus indicator. We have consistent agreement from many reviewers about the results of those edge cases. I encourage people who are considering a -1 on this, to assess those examples against the SC wording. I also encourage them to try the SC against their own real-world work.


  *   The “area” portion is far too complex



The SC provides a LOT of discretion for the designer to do a lot of funky things to achieve clear focus appearance with something other than a focus rectangle. With great power comes great responsibility. We looked at 100s of focus indicators and assessed dozens of edge cases to see how those fared against this wording, and iterated to make the wording better.

It is significant, to me, that one now has to WORK at creating a component and focus indicator combo  that achieves a borderline result that doesn’t obviously pass or fail and thus requires those calculations. I have not seen any examples since recent updates where I have thought ‘that is a good focus indicator and it fails!’ or ‘that is a bad focus indicator and it passes!’

Just like I would check text contrast on a variable-colour background, I’m likely going to have to go through the tedious process of checking pixels. I agree it’s a dreary occupation. I haven’t heard anyone saying we should abandon text contrast because, based on crappy design decisions, it can get harder to see if it barely passes or barely fails. I do know, even before carrying out this testing, that I’d be suggesting to the designer of this indicator that it’s a borderline focus indicator and they should improve it, regardless of its pass/fail result. Same message I convey to people who insist on putting text on an image background, etc.

The area portion does not usually take much time to assess if done methodically. I commend you for coming up with an example that makes it really hard.

In your example, the focus indicator is clearly more than 4 times the short side of the component. Area size is achieved.

How about contrast of that area? We need to assess both the focus indicator itself and against adjacent colours…

You’ve elected to put your focus indicator right on top of your variable drop shadow. Nice one! Let’s all acknowledge that by doing so you’ve made the indicator less visible as well as making it tougher to assess. If you’d offset the indicator, there’d be a better indicator and an easier test. So there’s a certain justice going on here.

Focus indicator pixel contrast first…
Often this could be quick to technically confirm (if the author uses colour X for component and colour Y for a directly adjacent focus indicator, is there is a 3:1 contrast for the pixels of the indicator?) but the box-shadow blur effect obfuscates the value. What I can do from your code is determine that the thickness of the indicator is only one CSS pixel, so I know if any of your pixels fails, the indicator as a whole cannot be used for the focus area size.
Your implementation makes it necessary to find the darkest pixel of a variable drop shadow, which can be a bit tedious with an eye dropper. But my testing showed that you’ve chosen to create a scenario where there is just under 3:1 contrast between your darkest pixels and the blue of the focus indicator. So, I can’t pass the whole focus indicator. (BTW,  I suspect it should be possible to write a number of automated tests to help check indicators; it might even be possible to determine the formula used in the blur effect and project the pixel colours from that.)
Someone’s going to have to do the even more tedious task of counting how many pixels are below 3:1 and work out if the remaining is an area equal to 4x the short side. At this time I would be telling the designer that their design is so borderline it’s going to require a lot of counting to confirm it passes, and invite them to do the counting OR simply do any of the numerous obvious things to improve this focus indicator.

So there’s motivation there to make it better. If this SC goes out the window, there is ZERO motivation or criteria to help convince the designer that this is not a good focus indicator.

For contrast against adjacent colors, unless the thickness is 2 px (automatic pass) I check the inner and outer contrast. The outer is an obvious pass here, given it’s the faded part of the drop shadow. The inner non-focus indicator color contrast is 6.6:1, so no problem there. Pass on adjacent.

In regard to complexity of calculations, unlike a whole whack of existing SCs, this requirement is designed to arrive at a clear pass with good inter-rater reliability. I’d like to contrast that with some existing SC that say things like ‘provide a text equivalent’ – a completely subjective condition. When one seeks to get repeatable results for a VISUAL aspect of design,  one must by its nature end up with something that is complex, or become highly prescriptive and restrictive.


  *   3. Content authors should not be held responsible for poor browser defaults

Some have been arguing that the browser defaults are now good, thus we need to allow folks to use them. The above statement presupposes the defaults are bad. Regardless, we have two criteria excepting use of browser defaults. Where authors elect to not alter the defaults, they pass. I didn’t hear an alternative proposal for defaults that got any traction.


  *   Yet what isn’t known is how long a focus indicator should persist to mitigate this problem.

Given we don’t have the research, I think it’s sensible to be conservative and stick with the decades’ long convention that focus indicators persist.

Is this SC perfect, no? Is it a lot better than what we have now to achieve good focus indicators? Absolutely. I encourage people to not let the perfect be the enemy of the good. This SC has better inter-rater reliability than the majority of our existing SCs. It offers an easy path to PASS, and for those who insist on making less visible focus indicators, it offers a way of measuring those.

Mike

From: Wilco Fiers <wilco.fiers@deque.com>
Date: Friday, July 15, 2022 at 6:28 AM
To: Alastair Campbell <acampbell@nomensa.com>
Cc: WCAG list (w3c-wai-gl@w3.org) <w3c-wai-gl@w3.org>
Subject: [EXTERNAL] Re: CFC - WCAG 2.2 Focus Appearance, Normative Text
-1 My concerns can be summarized in the following ways: 1. How to determine the size and shape of a component needs to be defined 2. The "area" portion is far too complex 3. Content authors should not be held responsible for poor
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd

-1


My concerns can be summarized in the following ways:


1. How to determine the size and shape of a component needs to be defined

2. The "area" portion is far too complex

4. Accessibility features are not properly accounted for


I've created a codepen with some examples.


Regarding component size; Knowing the exact size, shape, and position of a component is essential when applying this success criterion. Take a simple button with a box-shadow and a 1 pixel focus indicator for example. The focus indicator sits on top of the shadow, so whether or not the indicator encloses the button depends on if that shadow is considered part of the button or not. (example: https://codepen.io/wilcofiers/full/vYRXzRj<https://codepen.io/wilcofiers/full/vYRXzRj>)


Having had these discussions in AGWG, I believe the intent is for the shadow to be included, however the actual normative text leaves this largely open to interpretation. There are many other ways to determine the size and shape of a component, such as border box, content box, click area, etc. These can all be different. AGWG made several attempts to address this problem, yet kept finding problems it couldn't answer, and eventually settled on what to me looks like "let’s just leave it open".


I do not think this is a problem AGWG can leave unresolved. Testers will need to know how to do it. If WCAG normative doesn't tell them that, they'll have to make it up themselves. That is likely to result in an unnecessary amount of inconsistent WCAG tests.


Regarding complexity; This criterion has so many conditions, alternatives, sub-conditions, and exceptions it is really hard to keep track of. While determining a pass based on the "enclosed" item isn't too difficult, any focus indicator that’s on a background image with some dips in contrast, any indicator with some kind of fade to it, any indicator with gaps need to be evaluated with the “area” portion of the success criterion.


To do so accurately may require counting pixels of the focus indicator, and of the component (focused and unfocused), and making dozens, if not hundreds of contrast calculations. That would all be fine if it could be done automatically, but as per my point on "component size", AGWG decided not to define an automatable measure for component size. All of that will have to be done manually.


I believe that this success criterion is too complex to be workable in practice. The only good way to teach and apply this success criterion is by taking shortcuts. WCAG success criteria don’t just need to be accurate, they need to be teachable, and they need to be testable with a reasonable amount of effort. The success criterion as proposed is not.


Regarding browser defaults: This success criterion can, in many situations, require content authors to address problems caused by the default focus indicator of user agents. The user agent exception in the success criterion is too limited, and does not reflect the current state of technology. Several user agents today adjust the color of its focus indicator based on the background. Limiting the user agent exception to pages where the background wasn’t set is significantly underappreciating the ability of user agents to ensure the default focus indicator is accessible.


It’s one thing to require that Content Authors make what they author accessible to certain standards. It is another thing to require that they also overcome the accessibility deficits of a user agent. The W3C’s own Web Accessibility Initiative discusses how Accessibility has multiple essential components that interrelate at Essential Components of Web Accessibility<https://www.w3.org/WAI/fundamentals/components/>. The components described by Essential Components of Web Accessibility can be thought of as a “three legged stool”:


  *   Users
  *   User Agents: browsers, media players, assistive technologies, and other “user agents”
  *   Content Authors: designers, content contributors, developers, authoring tools


The Accessibility Guidelines Working Group’s (AGWG) charter only gives it the ability to provide normative guidance to content authors. That limitation does not mean that the AGWG should give content authors the responsibility to fix what is clearly a deficit of another “leg”. AGWG also should not absolve users from using the accessibility features of their user agents and other available assistive technologies. Expecting content authors to overcome user agent deficits is new territory for the Web Content Accessibility Guidelines and is going too far, putting responsibility in the wrong place.


Regarding accessibility features; Browsers like Chrome and Edge have an accessibility feature that can be enabled to add a focus ring to the page. This focus ring is impossible to hide with CSS, so when enabled, it guarantees a visible focus, (except in rare cases where focus is simulated such as on canvas). This focus indicator meets all the requirements of the proposed success criterion, except for one thing; persistence.


This accessibility feature fades out the focus ring after a few seconds, to avoid obscuring other content. The success criterion as written requires the focus indicator to persist while the component has focus. A focus indicator that fades away too quickly could be missed by people using screen magnification. Yet what isn’t known is how long a focus indicator should persist to mitigate this problem.


While some minimum duration is certainly important for focus indicators, the need for a persistent focus indicator has not been established. Requiring it in the success criterion limits the ability of browsers and other user agents to design novel solutions that address these problems for everyone. This discourages other user agent vendors from adding similar accessible focus indicator options.


Lastly, I do want to acknowledge and thank those who have worked on this Focus appearance success criterion. An incredible effort has gone into the development of this criterion. While I do not believe this success criterion is ready, it is impressive work nonetheless.


Kind regards,

On Tue, Jul 12, 2022 at 11:47 PM Alastair Campbell <acampbell@nomensa.com<mailto:acampbell@nomensa.com>> wrote:
Call For Consensus — ends Friday July 15th at midday Boston time.

The Working Group has previously discussed the WCAG 2.2 SC Focus Appearance and the Normative text needs to be approved by CFC.

It can be previewed in the editor’s draft:
https://w3c.github.io/wcag/guidelines/22/#focus-appearance<https://w3c.github.io/wcag/guidelines/22/#focus-appearance>

The SC has been discussed a lot, some recent and a key meeting:
https://www.w3.org/2022/06/28-ag-minutes#item05<https://www.w3.org/2022/06/28-ag-minutes#item05>
https://www.w3.org/2022/05/31-ag-minutes#item12<https://www.w3.org/2022/05/31-ag-minutes#item12>
https://www.w3.org/2021/12/03-ag-minutes#t05<https://www.w3.org/2021/12/03-ag-minutes#t05>

The change history is here:
https://github.com/w3c/wcag/commits/main/guidelines/sc/22/focus-appearance.html<https://github.com/w3c/wcag/commits/main/guidelines/sc/22/focus-appearance.html>
https://github.com/w3c/wcag/commits/main/guidelines/sc/22/focus-appearance-minimum.html<https://github.com/w3c/wcag/commits/main/guidelines/sc/22/focus-appearance-minimum.html>

The survey is available here:
https://www.w3.org/2002/09/wbs/35422/wcag22-focus-appearance-enhanced2/results<https://www.w3.org/2002/09/wbs/35422/wcag22-focus-appearance-enhanced2/results>

The github issues are listed here:
https://github.com/w3c/wcag/issues?q=is%3Aissue+is%3Aopen+label%3A%222.4.11+Focus+Appearance+%28min%29%22<https://github.com/w3c/wcag/issues?q=is%3Aissue+is%3Aopen+label%3A%222.4.11+Focus+Appearance+%28min%29%22>+
(There are 3 open, related to an understanding content updates.)

If you have concerns about this proposed consensus position that have not been discussed already and feel that those concerns result in you “not being able to live with” this decision, please let the group know before the CfC deadline.

Kind regards,

-Alastair
--

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



--
Wilco Fiers
Axe-core & Axe-linter product owner - WCAG 3 Project Manager - Facilitator ACT Task Force
[cid:BCBD7D4B-677E-4B95-AE3F-60005DBD9EE4]