Re: Clarifying WCAG 2.4.7 Focus Visible

Hi Claire,

Your designers are not truly committed to making accessible products, simple as. I would bet anything that when they say “not wanted” it’s not from large scale user testing where a statistically significant number of users complained about the focus indicator, or it was clearly causing usability issues.

Even if it was the case, that’s their job to fix.

As Marc noted, focus design is often neglected, to the detriment of sighted users of assistive technology, every user of the product and eventually designers themselves. Well designed and thought-out focus states (not the browser defaults) can be aesthetically pleasing and another opportunity to enhance the bran in the UI. They also make products a delight to use.

I lead design teams and when I encounter things like this, it’s a red flag on the understanding of accessibility and inclusivity, but also an opportunity for designers to really elevate their craft.

From: Taliesin Smith <talilief@gmail.com>
Date: Thursday, 1 June 2023 at 18:43
To: Claire Ryberg <contact@claireryberg.com>
Cc: w3c-wai-ig@w3.org <w3c-wai-ig@w3.org>
Subject: Re: Clarifying WCAG 2.4.7 Focus Visible
Hi Claire,

Great question, and I feel like you could reframe it to be more about people and less about meeting a success criteria. The success criteria are based on minimum guidelines.

Not all people who need a little extra help seeing what is directly interactive use assistive technology beyond perhaps wearing glasses or contact lenses.

All sorts of people - old and young, cognitively diverse, diverse vision, diverse attention abilities - like and will benefit from well-designed highlighting of interactive elements.

And then there are all sorts of contexts, too, like bright sunlight, where focus highlights could make things easier to see.

I’d like to see evidence that "Focus states after clicking/tapping are not wanted or necessary.”

In my work on interactive simulations, diverse learners (with and without disabilities) who use mouse and touch seem to like our "interactive highlights” - a bright pink outline that appears on hover and activation - in addition to other styling that is applied to interactive elements.

In our case, we made “interactive highlights” an optional feature. Focus highlights (the same bright pink outline) appears by default for all learners who use alternative focus-based input methods - not just the keyboard and not just screen reader software. People who are completely blind likely do not care too much about focus highlights, but people with diverse forms vision really appreciate our focus highlights and our interactive highlights.

There are other interactive states besides focus that can be styled in ways that make your interactions broadly inclusive. For example, there are styling options for Link, Visited, Hover, Focus, Active states.

I hope this is helpful information.
Taliesin

~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~.~
Taliesin L. Smith
talilief@gmail.com<mailto:talilief@gmail.com>
taliesin.smith@colorado.edu<mailto:taliesin.smith@colorado.edu>

Inclusive Design Research Specialist
PhET Interactive Simulations
http://phet.colorado.edu/
Department of Physics
University of Colorado, Boulder






On May 31, 2023, at 6:19 AM, Claire Ryberg <contact@claireryberg.com<mailto:contact@claireryberg.com>> wrote:

Hi all,

I’m hoping someone can help clarify SC WCAG 2.4.7 Focus Visible (https://www.w3.org/WAI/WCAG21/Understanding/focus-visible.html) so my team can best meet the requirement on our web platform.

Currently on the application, a focus border is displayed on many of our interactive elements when they receive focus from a screen reader or a keyboard. This border, however, also shows up after clicking the elements when using a mouse or tapping it using a mobile device. We’re debating if the focus state when using a mouse or tapping is required to comply with WCAG guidelines for focus states.

Design team: “Focus states should only be displayed for input type fields or when using assistive tooling. Focus states after clicking/tapping are not wanted or necessary.”


Development team: “After interacting with an element in any way, the element should receive focus, and therefore display a focus state.”



What’s your view on this behavior? Is it expected to visualize a focus border after interaction (independently of the input method) to comply with the guidelines or does it suffice to only show the focus border when specifically using assistive tooling?

To be clear: we all agree that the focus state should appear for assistive tools such as keyboard and screen readers. The debate is about if it should also appear for tools such as a mouse, touch devices etc. The interactive elements we are discussing are things like: buttons, checkboxes, tabs, custom widgets, etc…


Thanks in advance,
Claire