RE: 2.4.7 Focus Visible

| … It's a pity that the WCAG has somewhat encouraged the mess with the current guidelines.

I believe that one of the reasons “this is a mess” is because it is really a browser requirement, for the end-user to determine preferences and settings, not an authoring requirement.
There are things that the author shouldn’t do that can block the browsers and plug-ins, and those should be in WCAG, but the rest is really a browser requirement to allow end user choice in settings.

For example, my user who has recovered from a traumatic brain injury prefers less distraction from those often “highly visible and annoying to them” visible focus indicators to their preferred plug-in that temporarily displays the mouse focus indictor which after a couple seconds fades away.

Touch-screens on laptops have also “changed the paradigm” for these TBI users. They do prefer to see the focus indication occur when they touch the element (visible feedback), same as some users prefer the audio tone when typing, when selecting a photo click, etc., while some users prefer to turn it off, because they can be constantly distracted by too many audio tones.  Again, when it’s a user preference and there are possible conflicting user needs, and needs that can change over time and familiarity with using browsers, then that’s a flag to me that it’s a user agent/browser requirement, not an author WCAG requirement.

Phill Jenkins
Ibm.com/able



From: Michael Livesey <mike.j.livesey@gmail.com>
Sent: Monday, July 10, 2023 4:18 PM
To: Patrick H. Lauke <redux@splintered.co.uk>
Cc: w3c-wai-ig@w3.org
Subject: [EXTERNAL] Re: 2.4.7 Focus Visible

It's not a straw man, Patrick, the compromise you talk of, accessibility on keyboard only, is not really accessibility at all, it is lip service. If you want an analogy, it would be like only having wheelchair ramps at the back door to government
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-vrJEwpjW0GU3zVK-NQOssrEc6GGuR2yG8FA5UKNNsQolF-p2yH2-13bkMj_Ha9Hn7ID0y9JfrO1S9Mb956k1KVyQnpC9DtEQj0S6PuJsC4MAM_Jt1TF0ljk0$>   ‌
ZjQcmQRYFpfptBannerEnd
It's not a straw man, Patrick, the compromise you talk of, accessibility on keyboard only, is not really accessibility at all, it is lip service.

If you want an analogy, it would be like only having wheelchair ramps at the back door to government buildings, behind the bins.

A little history about wheelchair access might be helpful. Despite years of campaigning from the 1950s, nothing really changed in terms of wheelchair access until the Americans with Disabilities Act was passed in 1990.

As previously discussed, forcing visually impaired users to use the keyboard to gain visual aids to focus is not accessible. In fact, it is worse than having no WCAG rating at all because at least there isn't the pretence of accessibility.

> such as in Firefox where after even one
> interaction with the keyboard at any
> point on the page, subsequent mouse
> clicks also trigger :focus-
> visible/default highlighting.

I agree, The above is a good UX, but it is not standard in Chrome so is again currently a strawman. If the above was WCAG, that one keyboard interaction required all further mouse clicks to result in default highlighting, it would be a much more robust option.

Although, I would then question, why the heck wouldn't all mouse events always show focus visible because requiring a single keyboard tab to switch on visibility seems absurdly complex and something few people would be aware of, thus further complexing this issue unnecessarily.

It seems to me this while issue is a mess.

It's a pity that the WCAG has somewhat encouraged the mess with the current guidelines.

M

On Monday, July 10, 2023, Patrick H. Lauke <redux@splintered.co.uk<mailto:redux@splintered.co.uk>> wrote:
>
>
> On 10/07/2023 21:25, Michael Livesey wrote:
>
>> 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.
>
> Now who's making strawman arguments? :focus-visible is not "no focus indication ever", as your comparison tries to suggest.
>
> Incidentally, *because* :focus-visible taps into the browser's own heuristics, it can take advantage of more advanced heuristics/approaches that browsers themselves implement, such as in Firefox where after even one interaction with the keyboard at any point on the page, subsequent mouse clicks also trigger :focus-visible/default highlighting. Maybe not a perfect solution for those who'd want it as a matter of course all the time, but again - a pragmatic solution that satisfies multiple stakeholders.
>
> Anyway, peace out, I look forward to seeing a pull request for an advisory technique...
>
> 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
>
>