Re: 2.4.7 Focus Visible

Just to note that Firefox does not trigger focus-visible from a mouse click
after a keyboard interaction on a page, as Patrick previously wrote. I just
tested this out as it appeared dubious and highly confusing UX.

However, regarding the focus-visible issue, MDN does caution the following:



*"CognitionIt may not be obvious as to why the focus indicator is appearing
and disappearing if a person is using mixed forms of input. For users with
cognitive concerns, or who are less technologically literate, this lack of
consistent behavior for interactive elements may be confusing."*

I would say that it is not just confusing to people with cognitive
impairment, it is confusing to all. I would argue that fact that MDN has
decided to raise this issue as a cautionary note would argue against it
being an authoring decision, but rather one that needs WCAG attention,
either as an Advisory, where nuance can be accomodated, or an outright AA
requirement.

On Mon, Jul 10, 2023 at 10:43 PM Phill Jenkins <pjenkins@us.ibm.com> wrote:

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