Re: 2.4.7 Focus Visible

>>Browsers right here and now are not showing focus on click

This is a circular argument. In the 1980's buildings had steps and no
wheelchair access, that is not an argument that they should continue to not
have steps. Were visual disability groups even consulted about best UX and
accessibility regarding mouse click focus? It sounds as if there wasn't
proper consultation.

>>Advisory techniques have no "power" though. They go beyond what is
required by WCAG, so - in my experience anyway - they're summarily
ignored by authors trying to meet WCAG

If this were true no one would add styles for mouse hover, but in actual
fact most developers add styles for mouse hover. Furthermore, if your
statement was true, why would there be an advisory for mouse hover! Again,
the argument against advisories is highly contradictory.

Since an advisory can do no harm, and is (in the straw polls I have made of
national visibility groups) the preferred UX for visually impaired users,
there isn't really an argument for not making one. It further acts as a
sign post.



On Mon, Jul 10, 2023 at 6:24 PM Patrick H. Lauke <redux@splintered.co.uk>
wrote:

>
>
> On 10/07/2023 17:59, Michael Livesey wrote:
> > There is already an advisory on 2.4.7 about mouse events, specifically
> > hover, regarding visibility and accessibility, to extend this advisory
> > to mouse click would be a natural and minimal approach. Therefore, I
> > don't think that the argument about failing this standard holds fast.
>
> Advisory techniques have no "power" though. They go beyond what is
> required by WCAG, so - in my experience anyway - they're summarily
> ignored by authors trying to meet WCAG. Sure, we can add an advisory
> technique that essentially says "focus *must* be visible even after a
> mouse interaction", using an explicit :focus style instead of
> :focus-visible, but I doubt it'll result in any change.
>
> > Your argument fails to address the actual point - that web accessibility
> > is made worse for accessible users due to the current standard because
> > it forces them to use the keyboard for navigation.
>
> Your counterargument fails to address what I already hinted at: that
> browsers right here and now are already NOT showing explicit focus
> indications as a result of mouse interactions through their heuristics.
> That is the current status quo in browsers. :focus-visible at least taps
> into the same heuristics as the browser already uses. And that the most
> sustainable approach here is to get *browsers/user agents* to provide a
> setting for users to say "always show me where focus is", rather than
> placing the onus on authors of web content to do this.
>
> > Your argument is instead as follows - because it is a late stage and
> > someone failed to address the actual use case of a accessible users,
> > it's now tough bananas. This is akin to someone decided steps are better
> > for wheelchair access to buildings, then on pointing out that
> > ramps/lifts are needed saying - tough bananas it's all been decided
> > folks. I don't think any reasonable person should ever accept that
> > argument, so I would be very disappointed if WCAG failed to even
> > consider doing something here.
> >
> > Whilst I agree that it is a late stage, I am sure you will agree, the
> > purpose of WCAG is not to make websites less accessible to disabled
> > users. Hence the suggestion that this is made an advisory.
>
> "Make websites less accessible" than what? As said, this is already the
> status quo of how browsers handle focus indication out of the box,
> without any author CSS, and it has been this way for over a decade now.
> As said, sure, we can have an *advisory* technique that goes above and
> beyond the actual requirement of 2.4.7, but I wouldn't count on that
> making any noticeable difference. Demanding browsers/user agents add a
> setting will be the action that will yield the most immediate benefit on
> all existing web content.
>
>
> Incidentally, a related discussion from a few years back:
> https://github.com/w3c/wcag/issues/301
>
> --
> 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
>
>

Received on Monday, 10 July 2023 18:20:36 UTC