SC 2.4.11 Focus Appearance fails to explain why authors are better enbled than UA at solving this

[philljenkins]

all 3 docs listed below fail to explain why with any supporting data or rationale having the requirement on the author (designer & developer using WCAG) is better than on the browser/AT (using UAAG). It seems the working group has reached a concesus that all end users need or want the same minumum or worse, same enhanced visual focus appearence - why? Why in light of foundational accessibility principles is the working group trying to make what seems to be a one-size-fits-all requirement and depart from the principle of separating semantics from presentation and end-user preferences?

Many discussions on cognitive design I've seen talk about things not being too distracting. End users with cognitive disabilities are easily distracted by minimally contrasting focus indicators. That disability class is not even listed, or was it ignored.

My personal expereince testing the recent feature setting in Chrome to show (briefly) a visible focus indicator with TBI users was terrible, they hated it, it was distracting, they couldn't block it out of their mental discussion.

SC 2.4.11
Understanding Focus Appearance (Minimum)
How to Meet Focus Appearance (Minimum)

[philljenkins]

At a minimum, how the 2.4.11 minimum and 2.4.12 enhanced metrics are used to "... set requirements to make it clearly distinguishable" but not distractable (not too clearly) to end users with cognitive impairments needs to be explained in the Intent.

Again, I think a better approach would be to word the requirement similary to how the wording in 1.4.4 Resize text (Level AA) was arrived at when moving from WCAG 1.x to WCAG 2.0 when zoom features were ubitiquosly implemented in browsers. Could you imagine how bad it would be now if some minimal font size would have been established back then insted of an end-user zoom preference controlled by the browser?

[alastc]

It seems the working group has reached a consensus that all end users need or want the same minimum or worse, same enhanced visual focus appearance - why?

From my perspective, because it is an often complained about issue. Mostly from people who use voice input, keyboard only, or with low-vision.

We tried to tackle it with non-text contrast in WCAG 2.1, but "adjacent contrast" was not sufficient to do that properly. Therefore it became a backlog item for 2.2 to tackle.

depart from the principle of separating semantics from presentation and end-user preferences

You also mentioned UAAG, but despite bugs being open for many years, several browsers have not acted on it at all. Edge did, and Chrome inherited that, but see my response about that.

Many discussions on cognitive design I've seen talk about things not being too distracting.

Could you elaborate on the scenario where that would become an issue? Particularly as "focus-visible" becomes more available in browsers, anyone using a mouse is unlikely to notice the keyboard focus styles.

The COGA task force is aware of the requirement and has not commented. (That doesn't mean it has been analysed by them in detail, but it didn't seem to ring alarm bells.)

[mraccess77]

@philljenkins Sites can implement "the :focus-visible pseudo-class applies while an element matches the :focus pseudo-class and the UA (User Agent) determines via heuristics that the focus should be made evident on the element. (Many browsers show a “focus ring” by default in this case.)" https://developer.mozilla.org/en-US/docs/Web/CSS/:focus-visible and pass this SC.

[patrickhlauke]

all 3 docs listed below fail to explain why with any supporting data or rationale having the requirement on the author (designer & developer using WCAG) is better than on the browser/AT (using UAAG)

in short, because browsers have mostly ignored many aspects of UAAG, and have historically (until recently) had absolutely shockingly bad default indication out of the box.

[JamesCatt]

Again, I think a better approach would be to word the requirement similary to how the wording in 1.4.4 Resize text (Level AA) was arrived at when moving from WCAG 1.x to WCAG 2.0 when zoom features were ubitiquosly implemented in browsers. Could you imagine how bad it would be now if some minimal font size would have been established back then insted of an end-user zoom preference controlled by the browser?

This is one of the points I was trying to get at on the other thread—that really the ideal solution we should aim for in the long run is to have focus indicators that are customizable by the user, rather than imposed by the author.

I understand the logic put forward by many others that "the browsers still haven't done it" so we should do this because it's better than nothing, although I disagree with it for exactly this reason—locking in an inferior solution will be potentially detrimental in the long run.

I guess maybe I'm just more optimistic that we can still get browser vendors to do the right thing. But then again I haven't been in this game as long as most others. 😃

[alastc]

I disagree with it for exactly this reason—locking in an inferior solution will be potentially detrimental in the long run.

The author can provide a better solution because they control the context, e.g. the background colour, and colour of the element. The browsers (thus far) apply the same style to all controls.

Currently, I find more sites which override the default to remove it, than use the default.

I honestly don't see much movement on this from the browsers, but if the browsers really did step-up, it wouldn't matter what the author had specified. I suspect the approach would need to be:

• Have a not very discernible default;
• Have an option for an improved focus style.

If it were an option, it could then over-ride the authors styles, and possibly be customised by the user.

Also, if browsers do (eventually) come up with a better solution, then the requirement is met, the author doesn't have to do anything.

[alastc]

Approved response:

---

all 3 docs listed below fail to explain why with any supporting data or rationale having the requirement on the author (designer & developer using WCAG) is better than on the browser/AT (using UAAG).

It has been a noted problem for many years, with bugs open on the major browsers. The requirement is on the author until the browsers do implement a better solution. If that happens, the requirement is met.

Also, there are scenarios where even the better default-indicators are not apparent due to the authors styling (e.g. dark button on white background). Therefore authors can provide a better solution even compared to the better default-indicators, and certainly can in the meantime.

Rain's comment tackled the TBI aspect.

[rainbreaw]

It is a fair concern that any kind of high contrast element or motion could be distracting or difficult for individuals who find these visuals harsh and overwhelming (including the example above, individuals with traumatic brain injury).

In the case of focus indicators, however, it is less likely that these will have a significant impact in an actual use-case for the individuals who may react to a highly visible indicator, for a few reasons:

• Focus indicators are specifically intended to be the direct result of user interaction and intent. The focus moves to a new location only when the user intends to make this happen.
• Focus indicators are designed to support individuals using keyboard or related non-pointer inputs, who may have no other way of knowing where they are. Pointer inputs like a mouse or touch would not display a focus indicator in an intended implementation.

Another perspective from the cognitive side: a highly visible focus indicator can be supportive to some individuals who might benefit from additional emphasis in order to help them recognize where they are or what has changed.

[alastc]

With Rain's addition, the group agreed with the response above.
https://www.w3.org/2021/08/03-ag-minutes.html#item11