Re: 2.4.7 Focus Visible

Hi Julia,

I would suggest that the preamble to Advisory Techniques is certainly
exactly what we are talking about with :focus-visible

*"Advisory techniques* are suggested ways to improve accessibility. They
are often very helpful to some users, and may be the only way that some
users can access some types of content."

As to the flavour, well, that rather depends on how controllable browsers
make the heuristics for :focus-visible control. Perhaps at some future date
browsers will allow users to switch off focus-visible for keyboard input,
it is supposed to be under user agent control after all. Even though this
is unlikely to happen, the specification for heuristics is completely up to
browser manufacturers, they are not obliged to follow the current
behaviour, therefore we could loosely use that to conform with.

"They may not be sufficient to meet the full requirements of the success
criteria;"

https://www.w3.org/TR/selectors-4/#the-focus-visible-pseudo

The focus-visible specification rules are NON-NORMATIVE and therefore fully
compatible with "They may not be sufficient to meet the full requirements
of the success criteria;" I draw you attention to the specific wording here
- "MAY NOT". Even if there is a 0.1% chance that they may not meet the
criteria we cannot say that they do meet the criteria and because the
focus-visible rules are non-normative in the spec, at the time of writing
we cannot say with absolute certainty that they will always meet this
success criteria.

But let's be clear about this. Partick has even accepted in this discussion
that the narrow specification of 2.4.7 is bad UX for visually impaired
user, therefore whatever justification we use to add an advisory for
"focus-visible" to 2.4.7, we  should give ourselves a wide margin of
interpretive licence to do so to make this criteria better.

Another justification could be

"they may be based on technology that is not yet stable;"

We have already seen in this chat that Patrick discovered recent tweaks and
changes to Firefox, we have also seen that changing the heuristics for
focus-visible are also highly in flux and nobody is happy with the current
browser implementations in either Chrome or Firefox. Currently, in Chrome,
the only control is hidden behind a switch that flashes a large box over
the control, very few people are aware this also changes the user agent
heuristics for focus-visible. I would argue that this clearly shows that
the technology is not yet stable in that the browser implementation of the
heuristics neither stable nor currently accessible.

So again, whatever reason we use to make this an advisory, I think there is
ample room for interpretive licence here.

In fact, one could argue that they is not really a valid reason for not
making this an advisory, I hope you will agree.






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

> Hi Michael,
>
> 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?
>
>
> Well, I suppose it depends on which flavor of advisory technique you're
> going for.
>
> From the Understanding doco:
> "Advisory Techniques
>
> *Advisory techniques* are suggested ways to improve accessibility. They
> are often very helpful to some users, and may be the only way that some
> users can access some types of content.
>
> Advisory techniques are not designated as sufficient techniques for
> various reasons such as:
>
>    -
>
>    they may not be sufficient to meet the full requirements of the
>    success criteria;
>    -
>
>    they may be based on technology that is not yet stable;
>    -
>
>    they may not be accessibility supported
>    <http://www.w3.org/WAI/GL/UNDERSTANDING-WCAG20/conformance.html#uc-accessibility-support-head> in
>    many cases (for example, assistive technologies do not work with them yet);
>    -
>
>    they may not be testable;
>    -
>
>    in some circumstances they may not be applicable or practical, and may
>    even decrease accessibility for some users while increasing it for others;
>    -
>
>    they may not address the success criterion itself, and instead provide
>    related accessibility benefits.
>
> Authors are encouraged to apply all of the techniques where appropriate to
> best address the widest range of users' needs."
> It seems as if the advisory you would be proposing would follow this
> flavor: "in some circumstances they may not be applicable or practical,
> and may even decrease accessibility for some users while increasing it for
> others;" - Except that focus-visible is applicable and practical, and
> (covering the other bullet points) is sufficient to meet the SC, is based
> on stable technology, is accessibility supported, is testable, and does
> address the success criterion itself.
>
> Can you point to any other advisory techniques that fully meet the
> normative requirements of the SC but outline a technique which "decreases
> accessibility for some users while increasing it for others"?
>
>
>
> On 7/11/2023 1:48:51 PM, Michael Livesey <mike.j.livesey@gmail.com> wrote:
> >> 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
>>>
>>>