Re: Clarifying WCAG 2.4.7 Focus Visible

Short answer: the SC requires visible focus - tapping, hovering or clicking are not focus.

Anyway it can make a lot of sense to make these states also distinguishable. That’s why there are different states like focus, active, hover, visited and link (aka nothing).

And if the designers don’t like the look of the focus design - whose job would it be to fix this? 😉

Off topic: In my personal opinion focus design is massively underrated. It’s a chance to make the CD unique. Especially for web apps where it is much more likely that people use the keyboard. I’ve seen so beautiful designs with subtle animations, that I wonder why not everyone is doing this kind of extra exciting stuff.

Of course people will see the focus design much more often if using the product with a keyboard is as easy or even timesaving compared to mouse interaction.

So when these things come together (a great mouse less ux and a nice focus design) it will be a pleasure to use the product with the keyboard.

At this point the effort you put in a11y returns a real value for every user!

--
Mit freundlichen Grüßen

Marc Haunschild
https://Accessibility.Consulting


Am 01.06.2023 um 18:13 schrieb Claire Ryberg <contact@claireryberg.com>:



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