Re: 2.4.7 Focus Visible

Hi everyone,

This thread popped up for me because we’ve had complaints of off-list abusive emails, so with my chair hat on:

Please be considerate (or at least professional) on this list, and if you wouldn’t say something on-list, it probably shouldn’t be said directly either.
This thread triggered Shawn’s email:
https://lists.w3.org/Archives/Public/w3c-wai-ig/2023JulSep/0072.html

The key thing for me is: It is not about the people engaged in this discussion, it is about the concepts, ideas and potential actions. Keep the focus off the participants and on the ideas.

Chair hat off, on the substance:

> focus states are not ONLY used by keyboard users in practice, indeed most visually impaired users predominantly rely on the mouse for navigation, not the keyboard, and rely on visible focus and hover states because they find the pointer hard to see.

This is true, but there are differences in the scenarios. If someone relies on visual non-mouse access, being able to see what has focus is vital. It is a blocker if it is not there.
If you are looking at the screen and using a mouse, seeing the focus can be very useful, but you have other means of determining it. E.g. the location of your mouse pointer. Operating systems and the AT for people with low vision also include ways of making the pointer more apparent.

At least when 2.4.7 was written, there were also scenarios where forcing sites to include a focus indicator for mouse usage was not desirable. It was before my time on the group, but I’ve heard that some folks with certain cognitive impairments found them difficult/distracting (and Phil provided an example of that). Where there is not a clear solution across disability groups we have to lean more on personalisation/customisation rather than author requirements.

For many years the arguments when designing sites were about having focus indicators or not, given the sometimes ‘ugly’ effect of seeing it on-click. I’ve written about that before: https://alastairc.uk/2016/09/fixing-outlines-on-click/
Often everyone lost-out on focus indicators due to that.

At least with focus-visible we can avoid the scenario where the person in charge decides to remove all indicators for mouse usage and that also removes the keyboard indicators. It then puts the decision onto the user-agent.

Some scenarios where an on-click focus-indicator may not be desirable:

  *   Clicking on some text should generally not add a focus-indicator to the wrapper element. However, if you have a box with scrolling text, you do want a focus indicator when using the keyboard and landing on the wrapper.
  *   Clicking a link and the page loads new content dynamically. You may want to move the keyboard / screenreader focus to the new content, but showing a focus indicator would not be desirable there.
  *   Some controls (like checkboxes) show changes on-click, adding focus styles to that is superfluous, or at least not as important as other scenarios.
  *   If you click a link and it loads a new page, do you really want a flash of focus-indicator?

Overall, we can’t wave away the complexity of the scenarios and just demand on-click focus-indictors in all circumstances.

On the process:

For WCAG 2.2 we could add advice in the understanding document, and/or an advisory technique. It would be an indication of desirable behaviour, for those folks who pay attention to that. It would not solve people skating very close the normative baseline.
That would just need someone to take on that task, and there would a bit of a wait for it to be reviewed as we have quite a large backlog of small updates.

For WCAG 3.0 we are trying to build in more nuance, where things that would be AAA or advisory in WCAG 2.x can have more weight. It would also help to compile evidence for the need, so that when the guidelines are formed they can incorporate that.
A couple of people said things to the effect of: low-vision users always want focus indicators on-click. I’m not convinced by that. I totally agree that there are some scenarios where it is very difficult and confusing not to have the focus indicator on click, and that is what people would report.
However, that doesn’t mean it applies to all type of control all the time. I suspect there is a sub-set of scenarios where it is important, and we need to establish what those are. (Or establish that it is all controls, I could be wrong, but we need the evidence.)

So, the (productive) next steps are to write-up some advice now and collect evidence for future.

Kind regards,

-Alastair

--

AGWG Co-Chair
@alastc / www.nomensa.com<http://www.nomensa.com/>