Re: 2.4.7 Focus Visible

>> As I've watched this conversation at first my impression was that you
didn't understand the normative requirement of the Focus Visible SC 2.4.7.
It's clear, however, that you do
>> understand it - you just disagree with how narrowly it has been scoped
and hope that an advisory technique would dissuade some developers from
implementing visible focus
>> for only keyboard interactions.

I wouldn't put is quite like that, but almost, yes.

>> I don't know how much traction an advisory technique will get when it
explicitly contradicts the normative language which permits the
implementation of the thing being advised against.

Would an advisory would be "contradictory"?. As Patrick points out the
normative language does not tell developers to obliterate focus-visible. An
advisory to that effect would therefore not be contradictory would it?

 The question then becomes, what harm can an advisory do? Having erred in
the normative language by too narrowly scoping the AA criteria, is it then
better to compound that error by falling silent and acquiescing to terrible
UX, or is an advisory both the reasonable and correct thing to do?


On Tue, Jul 11, 2023 at 9:01 PM Juliette McShane Alexandria <
mcshanejuliette@gmail.com> wrote:

> Hi Michael,
>
> If I might weigh in here..
>
> As I've watched this conversation at first my impression was that you
> didn't understand the normative requirement of the Focus Visible SC 2.4.7.
> It's clear, however, that you do understand it - you just disagree with how
> narrowly it has been scoped and hope that an advisory technique would
> dissuade some developers from implementing visible focus for only keyboard
> interactions.
>
> However, as Patrick says, the language of SC 2.4.7 is normative and for
> all intents and purposes cannot be changed (without a new WCAG version). I
> don't know how much traction an advisory technique will get when it
> explicitly contradicts the normative language which permits the
> implementation of the thing being advised against.
>
> I've know Patrick professionally for awhile now and I believe that he
> wants the best experience for all users. He's also been steeped in
> specification writing for long enough that he has realistic and pragmatic
> views on what they can and cannot do, and how difficult they are to change.
> In this case I believe his stance is "A rule is a rule. If you don't like
> it and you want other people to do something different, get the rule
> changed." I don't think I've read anywhere in this thread that he's
> advocating for the focus-visible approach above other approaches. He's
> simply defended focus-visible as a method to pass the narrow normative
> language of this specific SC. In fact, the discussion about getting it
> browser-based is in furtherance of people being able to have choices beyond
> focus-visible and still make designers/clients happy.
>
> Cheers to you both. We all want the same thing.
>
> Best,
> Juliette
>
> On 7/11/2023 12:36:19 PM, Michael Livesey <mike.j.livesey@gmail.com>
> wrote:
> We both know that the lowest standard often becomes the standard. Thus by
> setting the bar extremely low, to the point of being a worse UX for
> visually impaired users, it follows that the WCAG is encouraging the
> obliteration of focus-visible behaviour. Something you even said yourself
> was a hard fight to win. So on winning the fight for focus-visible, you set
> a standard that tells developers that they can ignore it and still get AA
> accreditation???
>
> What is interesting about my position? That I want visual impaired users
> to actually be able to see what they have clicked? That I want
> focus-visible to work if they set it to show focus on click. I am not sure
> that is particularly interesting.
>
> On Tue, Jul 11, 2023 at 8:25 PM Patrick H. Lauke <redux@splintered.co.uk>
> wrote:
>
>> On 11/07/2023 20:15, Michael Livesey wrote:
>>
>> > Thus it follows that the WCAG wording in 2.4.7 actually encourages a
>> > worse UX for a accessible users than either focus or focus-visible, the
>> > browser default behaviour.
>>
>> WCAG does not encourage anything of the sort. WCAG sets a baseline
>> lowest limit of what sites must do in order to comply.
>>
>> If you're concerned that WCAG's baseline is too low and should be
>> raised, then I suggest you propose a new, stricter Success Criterion,
>> and get that approved by both the working group and the various
>> stakeholders involved in ratifying WCAG.
>>
>> > Your position is very interesting, Patrick.
>>
>> And so is yours, Michael.
>>
>> 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
>>
>>