RE: 2.4.7 Focus Visible

|… If the control does not have the potential for keyboard input - e.g. a link or a button

Hmm, I currently see a focus indicator on many links and buttons when tabbing to links and buttons, but when using the mouse to hover over the element I see the pointer cursor change.  I may not be understanding what you mean by “potential for keyboard input” and/or the difference between focus and hovering between the mouse and keyboard. I see the cursor change to an “input cursor” (from a pointing cursor), and most browsers allow me to change the style and size of the “input cursor” and “pointing cursors”.

|… ONLY non-pointing (e.g. keyboard) devices will trigger focus-visible classes.

When I “click” on the input element, the focus indicator also appears (as it should), but not before clicking with the mouse and not before tabbing to the element.

Are you suggesting the focus indicator should not ever appear at that point?
I would not support that interaction pattern.

Phill Jenkins
ibm.com/able
Hi Juliette, Yes, I completely agree. I too would rather guide a client towards a quality focus inidcator. I am particularly concerned though with how focus-visible operates and the confusion it has caused. Even Patrick appears not to appreciate
ZjQcmQRYFpfptBannerStart
This Message Is From an Untrusted Sender
You have not previously corresponded with this sender.
    Report Suspicious  <https://us-phishalarm-ewt.proofpoint.com/EWT/v1/PjiDSg!12-vrJEwpjW0GUpa0s4NghZuLyAn-ndBDJqktd4ujzFvct94joNddDakZc-2J2eUcRU74k-YLJyUtQKI66Hn18isaHmJcMd8rxUv-DnN86a8DA5CKZHP7jAHxRA$>   ‌
ZjQcmQRYFpfptBannerEnd
Hi Juliette,

Yes, I completely agree. I too would rather guide a client towards a quality focus inidcator.

I am particularly concerned though with how focus-visible operates and the confusion it has caused. Even Patrick appears not to appreciate how it operates, suggesting on Firefox a single keyboard use will trigger it for subsequent mouse clicks.
For the avoidance of doubt, the default behavious of focus-visible is as follows.
If the control has the potential for keyboard input - e.g. textarea/input etc, BOTH mouse clicks and keyboard will trigger a visible focus ring
If the control does not have the potential for keyboard input - e.g. a link or a button, OR it is a custom control whether or not it supports keyboard input, ONLY non-pointing (e.g. keyboard) devices will trigger focus-visible classes.
If scripting causes focus to move from a previously focus-visible item, then the newly focused item will also be focus-visible
So already we have a divergence with the WCAG guidelines in the case of controls which support keyboard input where mouse clicks will also show a visible focus.
A can of worms doesn't even begin to describe the conditions under which focus-visible will and will not show a visible focus ring. I am sure most developers are unaware of the nuances of its operation. Browsers manufacturers are also free to choose their own criteria for the above resulting in different behaviour which is, in my opinion, also not compatible with accessibility guidelines, which should be consistent.

On Mon, Jul 10, 2023 at 9:57 PM Juliette McShane Alexandria <mcshanejuliette@gmail.com<mailto:mcshanejuliette@gmail.com>> wrote:
Hi Michael,

At the risk of re-opening this somewhat closed can of worms...

I do not disagree with the consensus that visible focus indicators for mouse and keyboard interaction have benefit for many users with a range of accessibility needs. I also agree that the lack of a focus indicator for mouse users, for example when opening a new browser instance or moving to another window and then back as described in this thread, is a very poor experience for some users.

However, the Focus Visible SC only requires "a mode of operation" (emphasis added) where the focus is visible. It also does not require a specific size for the focus indicator, so a single pixel change would satisfy this SC. Given this, and the additional requirement from SC 1.4.11 that focus indicators (because they indicate the state of the control) have 3:1 contrast with the page background, an organization could very well claim they conform to WCAG with a 1px focus indicator of sufficient contrast that is only visible through the mode of keyboard operation - essentially a tiny dot of change when using keyboard would pass. Please note I am NOT advocating for these kinds of implementations, approaches, or attempts at circumventing the intent of the SC through technical loopholes. But - that's what the standard says, and unless normative changes (not any technique, sufficient or advisory) will change those minimal requirements.

In my current position I don't have a whole lot of interaction with folks in the public education sector and only a bit with governmental orgs, but I did at my first organization. I honestly can't say that it wasn't all that much different than the e-commerce I'm now primarily working with, except that the educational/government clients were usually requesting services in response to a Office of Civil Rights complaint or as a requirement of procurement processes as opposed to a plaintiff's demand letter.

Through my interactions with other accessibility professionals who work exclusively in the public educational/governmental space, and - just as importantly - as a direct employee as opposed to an outside vendor or consultant, my perception is that those embedded teams are much more apt to implement best practices as opposed to minimal compliance. I believe this is because they have the authority within their organization to do so because of the various mandates requiring it. This accessibility purist position is a wonderful one to be in, but not one that the great majority of accessibility folks enjoy. And this is not to minimize the fact that I'm sure embedded accessibility teams do get pushback from people about accessibility implementations - it is just to say that they are much more likely to "win" the argument than a vendor or contractor.

I, for one, would rather guide a client towards a quality focus indicator for keyboard users than have them insist on one that is so watered down as to be practically useless for everyone (which can still happen while achieving 3:1 contrast).

Best,
Juliette

On 7/10/2023 1:25:46 PM, Michael Livesey <mike.j.livesey@gmail.com<mailto:mike.j.livesey@gmail.com>> wrote:
It depends on who the client is, Juliette.

WCAG accessibility matters a great deal to educational and governmental clients, who put accessibility AA at the top of their priorities. Where the importance of WCAG rules and advisories comes into play is ensuring that where clients are interested in making their sites AA compliant, that the guidance does actually achieve an end result that improves accessibility not result in a detriment.

Clients may well be only interested in A level accessibility or lower, or not interested at all. It isn't compulsory to meet any WCAG standards, it is entirely optional. But what we shouldn't have is clients claiming AA standards and paying lip service to accessibility facilitated by focus-visible only styles.

So I would argue that there isn't a third stakeholder here. The third stakeholder doesn't get to claim their premises are wheelchair friendly without a ramp/lift, they don't get to claim they are disability friendly having toilets on the fifth floor, why should they get to do the same for their web sites.









On Monday, July 10, 2023, Juliette McShane Alexandria <mcshanejuliette@gmail.com<mailto:mcshanejuliette@gmail.com>> wrote:
> I've been watching this conversation unfold and I just have to put in my 2 cents.
> Neither of you (unless I missed it) addressed a 3rd stakeholder. We have end users, we have developers, and then we have the designers or client enforcer of the "Brand" look and feel across the site.
> We are actually working on a site right now where our client (as required by her creative director) is having us implement :focus-visible precisely because the client doesn't want mouse users to experience them. And I quote: "I know I mentioned prior when clicking on the navigation or search the whole word was outline in a box. Its hard because we don’t want to take away from the beauty of the site with the clunkiness of the box. "
> I'd say that this client is only moderately clinging to their visuals when we have something which requires a visible adjustment for visibility. We've definitely had clients who fought every single little visual change, even keyboard-only focus indicators. I view :focus-visible implementations as an often necessary compromise between client/design requirements and accessibility best-practice. Neither party gets the best solution, but it's better than it was.
> Also, FWIW, most developers/engineers, unless specifically implementing accessibility, don't even know that WCAG has techniques. Whether or not this was an advisory technique I think would have little to no impact on the vast majority of website builds, at least in the current landscape.
> Best,
> Juliette
>
> On 7/10/2023 12:05:28 PM, Patrick H. Lauke <redux@splintered.co.uk<mailto:redux@splintered.co.uk>> wrote:
>
> And as I said, I'm not stopping you from proposing/submitting an
> advisory technique, just cautioning that by the very nature of the
> advisory it will still mean that there will be plenty of authors that
> either don't even know about it, or that they decide not to apply it
> even if they do know about it.
>> It seems to me, however, that most visually impaired users always do
>> want focus on click, so I really don't buy the nuance argument here.
>
> The nuance here is that WCAG is not just aimed at visually impaired users...
>
> P
> --
> Patrick H. Lauke
>
> https://www.splintered.co.uk/<https://www.splintered.co.uk/> | https://github.com/patrickhlauke<https://github.com/patrickhlauke>
> https://flickr.com/photos/redux/<https://flickr.com/photos/redux/> | https://www.deviantart.com/redux<https://www.deviantart.com/redux>
> https://mastodon.social/@patrick_h_lauke<https://mastodon.social/@patrick_h_lauke> | skype: patrick_h_lauke
>
>