[WCAG 2.2 Feedback] Success Criterion 2.4.11 Focus Appearance (Minimum) (Level AA)

[dshoukry]

"Success Criterion 2.4.11 Focus Appearance (Minimum) (Level AA): When user interface components receive keyboard focus, all of the following are true:
Contrasting area: There is an area of the focus indicator that has a contrast ratio of at least 3:1 between the colors in the focused and unfocused states.
Minimum area: The contrasting area is at least as large as:
Outline: the area of a 1 CSS pixel thick perimeter of the unfocused component, or
Shape: the area of a 4 CSS pixel thick line along the shortest side of a minimum bounding box of the unfocused component, and no thinner than 2 CSS pixels.
Adjacent contrast: The contrasting area also has a contrast ratio of least 3:1 against adjacent colors in the focused component, or the contrasting area has a thickness of at least 2 CSS pixels.
Not fully obscured: The item with focus is not entirely hidden by author-created content."

We are still very concerned about this SC, and the difficulty and subjectivity required to consistently implement this on components with "unusual shapes". A few of us got lost in the implementation options/steps and exceptions and couldn't follow what is actually compliant. Could this be simplified to using higher contrast requirements or higher highlight contrast + thickness? And perhaps use some of the requirement numbers in the v2 of the Enhanced AAA requirement? Can the group share more around the data/decisions that influenced the changes for the latest round of updates in the AA vs AAA SC?

Please find detailed specifics covered in our 2.4.11 Focus Appearance (Minimum) (Level AA) Google Doc.

[alastc]

Hi @dshoukry,

Approved response to specific comments in the doc:

---

Can the group share more around the data/decisions that influenced the changes for the latest round of updates in the AA vs AAA SC

The previous issues and changes are documented in github, there are a lot so a more specific question might help.

Overall though, the process has been to try and come up with the best mechanism to test the aspects outlined in our previous response, where the main factors that go into the visibility, from some 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.

Could we specify and clarify the difference between application-level focus and element-level focus?

I'm not clear if that is about native apps, or a scenario where a web app has multiple focus points? I think we need more info, and it would be worth considering how that scenario relates to the definition of user interface components.

There are many implementation options/steps and it's not clear what is actually compliant. Would it be possible to simplify this to using very high contrast or highlight contrast + thickness?

We could, but then typical (and reasonable) indicators that people use now would not pass. It would make a lot of websites have to do extra work in order to pass, when their current indicators are reasonably clear to users and pass the current SC text.

Does this also include background colors?

The adjacent contrast bullet specifically says "against adjacent colors in the focused component", so if you mean the background to the component (rather than of the component) then yes. We have tried to avoid saying 'background' because it can be misleading.

What counts as an unusual shape?

For web content, anything not a rectangle. All the examples above are rectangles, and then the examples in here are circles and stars.

We had raised feedback in the first round that several of us found this [star] example confusing and that this may be error prone and unclear.
... This [quick method] seems a bit too subjective. Could a more detail method be shared?

Originally we'd included a diagram of separating the indicator from the star and working out its size. However, several people commented that it looked too complex and was unnecessary. The simpler method was proposed instead.

Would it help to add a line about comparing the focused/unfocused state and counting pixels? It is an unusual scenario, for most (unusual) shapes you can work it out mathematically more easily.

The dropshadow may get "lost" in a high contrast mode. Outlines may be a more reliable style indicator than shadows for some components in these environments.

This criterion is about the authored styles, if people over-ride that it is out of scope.

A few of us found the references to "bullets" throughout this section to be rather confusing. Direct links to that content might help given how long this specific criterion is.

Good point, it would probably help to include a snippet of the SC text under each heading.

As written, this sentence implies that the use of color alone is an acceptable method to indicate that something has changed. Can a cross-reference be made to avoiding communicating information via a single sensory characteristic?

It depends what you mean, changing some pixels from white to black is a "change of color" in the general sense. However, it could be adding an outline, so that type of 'change of color' is considered ok.

Overall though, there is a general point in WCAG 2.x that a change of contrast is more than a change of colour.

Thanks for the editorial updates, we'll implement those.

[alastc]

The editorial updates are in #2000

[alastc]

Response approved in the last meeting: https://www.w3.org/2021/09/14-ag-minutes.html#item07