Re: Clarifying WCAG 2.4.7 Focus Visible

This debate has cropped up a number of times in recent years.

Hopefully it is clear to your team that anyone who wants to use a keyboard at any given moment relies on the context of a focus indicator to understand where their current point of interaction is on the screen. Hence the explicit wording in 2.4.7 Focus Visible, “where the keyboard focus indicator is visible”.

The “mode of operation” wording gives some flexibility to a design to decide when to expose that keyboard focus. Some have elected to curtail keyboard focus when they believe the user is operating by pointer.

“Belief” is the operative word there. Many people move between different modes of operation during interaction with a page or application.  This is covered explicitly by 2.5.6 Concurrent Input Mechanisms<https://www.w3.org/WAI/WCAG21/Understanding/concurrent-input-mechanisms.html>. Given that reality, a team considering actively curtailing focus indication in an interaction should have good research to back up their design decision. I’d be surprised if there’s significant negative effect on time on task for pointer-only user. I’m sure they’ll find negative effects on multi-modal users. Let the data guide the decision.

Mike


From: Claire Ryberg <contact@claireryberg.com>
Date: Thursday, June 1, 2023 at 9:14 AM
To: w3c-wai-ig@w3.org <w3c-wai-ig@w3.org>
Subject: [EXTERNAL] Clarifying WCAG 2.4.7 Focus Visible
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
ZjQcmQRYFpfptBannerStart
This Message Is From an Untrusted Sender
You have not previously corresponded with this sender.
ZjQcmQRYFpfptBannerEnd

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<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