Re: 2.4.7 Focus Visible

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 [mailto: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 [mailto: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 [mailto: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://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