Re: 2.4.7 Focus Visible

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> 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> 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> 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>
> 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://github.com/patrickhlauke
> > https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
> > https://mastodon.social/@patrick_h_lauke | skype: patrick_h_lauke
> >
> >
>
>