Re: 2.4.7 Focus Visible

Hi Alastair,

>> For WCAG 2.2 we could add advice in the understanding document, and/or
an advisory technique.

This would be great. I do not claim to have the answer for what would be
the best form of words for the advisory, which is why I haven't raised a
PR. Being a late stage it is a delicate balance. As you say, it wouldn't
stop developers from deliberately abusing the true intention of 2.4.7 by
skating close to the wind, but my feeling is that an advisory is better
than no advisory. An advisory now would then not be a shock if WCAG 3.0
gave more weight to expanded conformance requirements for focus visible.
Also, by WCAG 3.0 the focus-visible selector will hopefully be better
supported in terms of user agent controls in browser settings, so everyone
can have the experience they want.

Even mobility-disabled users don't always choose the keyboard when they
can't use a mouse. There are a plethora of alternative input devices -
touch screen, pointers, tablets, eye pointers, pens, track balls etc - all
of which count as pointing devices and thus could get no visible focus as
the criteria currently stand. Pens in particular are problematic because
the pointer vanishes as soon as one raises the pen, thus just as with the
keyboard tab, a visible focus is desirable.

My feeling is that a discussion as to what a potential advisory might say
would be productive, even if people disagree with there being an advisory,
perhaps if a form of words is found it might be something that no one is
particularly against, but could be somewhat supportive of those that would
like more strength to 2.4.7

On Fri, Jul 14, 2023 at 11:26 AM Alastair Campbell <acampbell@nomensa.com>
wrote:

> Hi everyone,
>
>
>
> This thread popped up for me because we’ve had complaints of off-list
> abusive emails, so with my chair hat on:
>
>
>
> Please be considerate (or at least professional) on this list, and if you
> wouldn’t say something on-list, it probably shouldn’t be said directly
> either.
>
> This thread triggered Shawn’s email:
>
> https://lists.w3.org/Archives/Public/w3c-wai-ig/2023JulSep/0072.html
>
>
>
> The key thing for me is: It is not about the people engaged in this
> discussion, it is about the concepts, ideas and potential actions. *Keep
> the focus off the participants and on the ideas*.
>
>
>
> Chair hat off, on the substance:
>
>
>
> > focus states are not ONLY used by keyboard users in practice, indeed
> most visually impaired users predominantly rely on the mouse for
> navigation, not the keyboard, and rely on visible focus and hover states
> because they find the pointer hard to see.
>
>
>
> This is true, but there are differences in the scenarios. If someone
> relies on visual non-mouse access, being able to see what has focus is
> vital. It is a blocker if it is not there.
>
> If you are looking at the screen and using a mouse, seeing the focus can
> be very useful, but you have other means of determining it. E.g. the
> location of your mouse pointer. Operating systems and the AT for people
> with low vision also include ways of making the pointer more apparent.
>
>
>
> At least when 2.4.7 was written, there were also scenarios where forcing
> sites to include a focus indicator for mouse usage was not desirable. It
> was before my time on the group, but I’ve heard that some folks with
> certain cognitive impairments found them difficult/distracting (and Phil
> provided an example of that). Where there is not a clear solution across
> disability groups we have to lean more on personalisation/customisation
> rather than author requirements.
>
>
>
> For many years the arguments when designing sites were about having focus
> indicators or not, given the sometimes ‘ugly’ effect of seeing it on-click.
> I’ve written about that before:
> https://alastairc.uk/2016/09/fixing-outlines-on-click/
>
> Often* everyone* lost-out on focus indicators due to that.
>
>
>
> At least with focus-visible we can avoid the scenario where the person in
> charge decides to remove all indicators for mouse usage and that also
> removes the keyboard indicators. It then puts the decision onto the
> user-agent.
>
>
>
> Some scenarios where an on-click focus-indicator may not be desirable:
>
>    - Clicking on some text should generally not add a focus-indicator to
>    the wrapper element. However, if you have a box with scrolling text, you do
>    want a focus indicator when using the keyboard and landing on the wrapper.
>    - Clicking a link and the page loads new content dynamically. You may
>    want to move the keyboard / screenreader focus to the new content, but
>    showing a focus indicator would not be desirable there.
>    - Some controls (like checkboxes) show changes on-click, adding focus
>    styles to that is superfluous, or at least not as important as other
>    scenarios.
>    - If you click a link and it loads a new page, do you really want a
>    flash of focus-indicator?
>
>
>
> Overall, we can’t wave away the complexity of the scenarios and just
> demand on-click focus-indictors in all circumstances.
>
>
>
> On the process:
>
>
>
> *For WCAG 2.2* we could add advice in the understanding document, and/or
> an advisory technique. It would be an indication of desirable behaviour,
> for those folks who pay attention to that. It would not solve people
> skating very close the normative baseline.
>
> That would just need someone to take on that task, and there would a bit
> of a wait for it to be reviewed as we have quite a large backlog of small
> updates.
>
>
>
> *For WCAG 3.0* we are trying to build in more nuance, where things that
> would be AAA or advisory in WCAG 2.x can have more weight. It would also
> help to compile evidence for the need, so that when the guidelines are
> formed they can incorporate that.
>
> A couple of people said things to the effect of: low-vision users always
> want focus indicators on-click. I’m not convinced by that. I totally agree
> that there are some scenarios where it is very difficult and confusing not
> to have the focus indicator on click, and *that is what people would
> report*.
>
> However, that doesn’t mean it applies to all type of control all the time.
> I suspect there is a sub-set of scenarios where it is important, and we
> need to establish what those are. (Or establish that it is all controls, I
> could be wrong, but we need the evidence.)
>
>
>
> So, the (productive) next steps are to write-up some advice now and
> collect evidence for future.
>
>
>
> Kind regards,
>
>
>
> -Alastair
>
>
>
> --
>
>
>
> AGWG Co-Chair
>
> @alastc / www.nomensa.com
>
>
>