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 browser defaults

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)

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>
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
>
>
>
> 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/05/31-ag-minutes#item12
>
> 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-minimum.html
>
>
>
> The survey is available here:
>
>
> 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+
>
>
> (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
>
>
>


-- 
*Wilco Fiers*
Axe-core & Axe-linter product owner - WCAG 3 Project Manager - Facilitator
ACT Task Force