Re: 2.4.7 Focus Visible

Hi Kevin,

hover, focus, and active are three very different things.

hover and active can affect any element and are ephemeral states related to
a transient action (e.g. pointer being moved over an element, or the
transient state between mouse down and mouse up respectively).

However, focus only affects elements that are focusable, these are usually
control elements or navigation related elements. The focus state for these
elements is retained after a click regardless of pointer location. Focus
lets the user know where they are on a page and what element will accept
the next input. It is triggered by both tab and a pointer click. The
confusing thing here is that even though a pointer click will focus a
control element, by following the current SC it will do so without actually
showing the element is focused.

I would definitely agree, a good hover indication is valuable, there is
already an advisory for this under 2.4.7. Therefore, regardless of the
recommendation for hover, I think focus support for pointer devices is a
separate but equally, if not more, important issue.

On Thursday, July 27, 2023, Kevin Prince <kevin.prince@fostermoore.com>
wrote:
> At this stage I’m going offline but I think that a better word is
required than focus – using the mouse causes an ohover event whereas it is
the keyboard that provides a onfocus. That’s potentially, and actually,
confusing.
>
>
>
> Onhover causes a mouse pointer change – now that is totally configurable
by the user already which achieves what you are looking for (in one sense).
When you move the mouse away that element is no longer either focussed or
hovered.
>
>
>
> If you click the element then that’s a Active indication. Only one of
these refers to Focus at a technical level: experientiually they probably
all do.
>
>
>
> Hope this helps a little with your formulation.
>
>
>
> Kevin Prince
> Product Accessibility & Usability Consultant
>
> Foster Moore
> A Teranet Company
>
> E kevin.prince@fostermoore.com
> Christchurch
> fostermoore.com
>
> From: Michael Livesey <mike.j.livesey@gmail.com>
> Sent: Tuesday, July 25, 2023 6:11 PM
> To: Siegman, Tzviya <tsiegman@wiley.com>
> Cc: Marc Haunschild (Accessibility Consulting)
<marc.haunschild@accessibility.consulting>; Patrick H. Lauke <
redux@splintered.co.uk>; w3c-wai-ig@w3.org
> Subject: 2.4.7 Focus Visible
>
>
>
> In my opinion, the point of the discussion now is to discuss a form of
words that could form the basis of an advisory.
>
> Given that 2.4.7 and 2.4.3 fall short at the moment of meeting the
conclusions of peer reviewed recommendations for accessibility, it would be
good if there was a discussion of wording that could address this issue.
>
> https://www.ncbi.nlm.nih.gov/pmc/articles/PMC2788505/
>
> Based on the discussion so far, my suggestion would be something like the
below. I can't really see any downside to it, it is compatible with the
current SC, it is compatible with the intent of :focus-visible (future
standard currently not fully implemented), and it will hopefully signpost
to developers not to only provide focus on keyboard or override
focus-visible, a signpost that in WCAG3.0 will become a SC.
>
>
> "It is important to keep in mind that the specific needs and preferences
of users with disabilities can vary greatly. Consider providing a clear
visual indication of focus for both keyboard and pointer users and ensure
that your focus styles can be easily enabled and disabled."
>
>
>
>
> On Wednesday, July 19, 2023, Siegman, Tzviya <tsiegman@wiley.com> wrote:
>> I mean this in the most polite way possible, but is this discussion
still productive? This thread about focus visible has been going on for
more than a week. I certainly have not read all the emails, but I wonder if
there is more information to add. It is clearly an issue that people feel
passionately about, but please consider whether this is a discussion that
should be perpetuated.
>>
>>
>>
>> Let’s refer to Shawn’s message about conduct
https://lists.w3.org/Archives/Public/w3c-wai-ig/2023JulSep/0072.html,
“Provide constructive information. Focus on developing solutions, rather
than just complaining.”
>>
>>
>>
>> Is this still constructive?
>>
>>
>>
>> Thank you,
>>
>> Tzviya
>>
>>
>>
>> Tzviya Siegman
>>
>> Information Standards Principal
>>
>> Wiley
>>
>> 201-748-6884
>>
>> tsiegman@wiley.com
>>
>>
>>
>> From: Michael Livesey <mike.j.livesey@gmail.com>
>> Sent: Wednesday, July 19, 2023 2:00 PM
>> To: Marc Haunschild (Accessibility Consulting)
<marc.haunschild@accessibility.consulting>
>> Cc: Patrick H. Lauke <redux@splintered.co.uk>; w3c-wai-ig@w3.org
>> Subject: Re: 2.4.7 Focus Visible
>>
>>
>>
>> ⛔
>>
>> This is an external email.
>>
>> PS :active is when the button is clicked. It is an ephemeral state.
Control elements that receive input require a :focus style otherwise visual
disable users wouldn't know which element will receive their next input,
nor where they are in the document should they use mix mode input, keyboard
then pointer, causing disorientation as the focus appears and disappears.
>>
>>
>>
>>
>>
>> On Wednesday, July 19, 2023, Marc Haunschild (Accessibility Consulting)
<marc.haunschild@accessibility.consulting> wrote:
>>> Hi Michael,
>>>
>>>>>I have no idea how a mouse user can benefit from a Fokus indicator.
>>>
>>> Visual disabled user cannot see the pointer clearly and benefit from a
clear indication of when they have clicked a control element.
>>>
>>> That’s not :focus nor :focus-visible, that’s :active.
>>>
>>> Users with cognitive impairment benefit from a focus indicator to help
them remember what they have clicked, the active element.
>>>
>>> Also “they” are distracted and/ or confused if one of many buttons in a
row is highlighted - some think that’s a warning or they just don’t
understand, why one of the buttons is different from the others.
>>> This even happens with people that don’t have cognitive impairments.
>>> So what do you recommend for the people who have problems with visual
focus on elements they don’t expect this behavior?
>>> Can write an advisory technique that both user groups take into
consideration?
>>>
>>> Mobility impaired users using a pointer type device that doesn't
display a constant pointer also benefit from a focus indicator.
>>>
>>> How you can click something when you don’t have a pointer?!?
>>> Do you have an example?
>>>
>>> There is a large number of accessible use cases that benefit from a
focus indicator on pointer click.
>>>
>>> Can you name at least three of them? Just the most common/ important?!?
>>> And please only those that don’t have it already anyway, when :focus is
visible. As far as I understand you only have problems with
:focus-visible?!?
>>>
>>>>>be very careful what to ask users! They're not experts!
>>>
>>> I think we need to be careful of telling users what is best for them.
Accessibility is about making the web as accessible as possible for as many
people as possible.
>>>
>>> So? It’s about numbers? In my opinion a11y is about the few with
special needs.
>>> And how do you know, that making a focus visible on every single
focusable element will be for more users a benefit than a distraction/
clutter? Where do these numbers come from? I’m very into researches and
never heard about one with this particular outcome. So make clear that this
is more than an assumption.
>>> And please: telling users what’s best for them? Really? After 20+ years
in the business you don’t get me with so simple platitudes.
>>> Again: users don’t know the solutions for their problems. They don’t
have the technical background and/ or understanding for the downsides of
their „solutions“.
>>> That’s just not how it works.
>>> Of course users opinions are important. We need testing with real
users. And than we provide improved prototypes made by a11y and UX experts
and users Test this again.
>>> This normally goes through a few or even many iterations and the result
should be something all users are satisfied with - also users that don’t
need the examined feature.
>>> That’s how it works. Not implementing everything somebody throws into a
discussion as a wish.
>>> We would have a web unusable for everyone if things would be
implemented in the standards like this.
>>> Discussions like this one are part of the standardization process and
the one who wants a technique to be added has to prove at least two things:
>>> 1. There really is a benefit
>>> 2. It does not harm other (or the same) users
>>> Again I’m not even sure whether we talk about focus, active, hover or
all of them. And maybe the users you are trying to help don’t even know
about the differences of these.
>>> Are you convinced you really know, what they want?
>>> That’s quite a task. I’m not sure we are already knowing what to write
in this advisory technique to make things better.
>>> Making things better is what everyone here wants to achieve. So don’t
get angry. That’s not helpful when you try to persuade people. Give the
necessary background information to make us understand the problem, the
proposed solution, which benefits and downsides there are for what kind of
users, so there is something to think about.
>>> It also helps to provide a text proposal for this advisory technique to
talk about.
>>> That’s a lot of effort for an advisory technique that very few people
will read and even less will consider to implement.
>>> As many (including yourself) pointed out: designers aren’t to eager to
design different states for buttons, links, text inputs, radios, checkboxes
and so on. It looks like fighting windmills to me. But feel free to go for
it. I always love a beautiful sustainable solution but honestly I don’t see
it yet.
>>> Marc
>>>
>>>
>>> On Tue, Jul 18, 2023 at 11:37 PM Michael Livesey <
mike.j.livesey@gmail.com> wrote:
>>>>
>>>> Just of note, this is the response provided by chatGPT when asked
about focus visible and accessibility for visually disabled users.
>>>>
>>>> "Visually disabled users may rely more on pointer-type devices, such
as a mouse or trackpad, rather than keyboard navigation. It is important to
keep in mind that the specific needs and preferences of users with
disabilities can vary greatly. Consider providing a clear visual indication
of focus for both keyboard and pointer users."
>>>>
>>>> The above seems along the lines of what I would propose as an advisory
to 2.4.7.
>>>>
>>>> ChatGPT went on to make the following comments.
>>>>
>>>> "Respect user preferences: Some users may have specific preferences
for focus styles or may use custom stylesheets to modify the appearance of
web content. Ensure that your focus styles can be easily overridden or
disabled by users who prefer or require alternative styles."
>>>>
>>>> "Test with diverse users: As accessibility needs can vary among
individuals, it's important to involve users with different disabilities in
your testing. Conduct usability tests with participants who use different
assistive technologies, such as screen readers, keyboard-only navigation,
or pointer devices, to gather feedback and ensure your focus styles work
effectively for a wide range of users."
>>>>
>>>>
>>>> On Sunday, July 16, 2023, Marc Haunschild
<marc.haunschild@accessibility.consulting> wrote:
>>>> > Hello everyone,
>>>> > There is even a much more simple way to address some persons needs:
plugins.
>>>> > As a matter of fact, there obvious are people wanting a focus
highlighting and people, that really have problems because of it.
>>>> > The best thing about accessibility is - in my opinion - that people
are free to use tools that help them meet there own needs.
>>>> > For example accessible ICT can be used with mouse and/ or keyboard
and/ or touch screen and/ or voice input…
>>>> > As HTML and CSS are well known standards, it’s not a big thing to
write a plugin or bookmarklet to change the design to your own needs.
>>>> > In the EU support of user settings is mandatory, so persuading
browser vendors to implement it, would be the more sustainable solution of
course…
>>>> >
>>>> > 11.7 User preferences
>>>> >
>>>> > Where Web-App is not designed to be isolated from its platform, and
provides a user interface, that user interface shall follow the values of
the user preferences for platform settings for: units of measurement,
colour, contrast, font type, font size, and focus cursor except where they
are overridden by the user.
>>>> >
>>>> > [...]
>>>> >
>>>> > NOTE 2: For web content, the underlying platform is the user agent.
>>>> >
>>>> > Of course all manipulation works better with valid HTML - which is
yet another reason to have back a SC that demands valid HTML, sigh…
>>>> > Standards are the only way to ensure compatibility for all UAs tech
stacks (OS, Browser, SR/ screen…), user tweaks and preferences. But that is
a discussion I gave up long ago. Still missing this particular WCAG 1.0 SC
nevertheless…
>>>> > — Marc
>>>> >
>>>> >
>>>> > Am 11.07.2023 um 01:43 schrieb Patrick H. Lauke <
redux@splintered.co.uk>:
>>>> > On 11/07/2023 00:07, Patrick H. Lauke wrote:
>>>> >
>>>> > On 10/07/2023 23:42, Michael Livesey wrote:
>>>> >
>>>> > Even Patrick appears not to appreciate how it operates, suggesting
on Firefox a single keyboard use will trigger it for subsequent mouse
clicks.
>>>> >
>>>> > Patrick does appreciate how it was implemented in Firefox
https://bugzilla.mozilla.org/show_bug.cgi?id=1445482#c19, but Patrick must
have missed a recent change that tweaked that behaviour.
>>>> >
>>>> > And now these repressed memories are finally coming back to me ...
here are the bugs I filed back in the day about getting browsers to
implement an override switch to allow :focus-visible to always kick in even
after mouse/pointer interaction. Boosting this/lobbying browsers to do this
has, in my view, a much greater chance to provide a simple solution that
then satisfies all different constituencies/stakeholders, and again puts
the control back in users hands/preferences (rather than pushing/advocating
for one solution for everybody)
>>>> >
>>>> > https://bugzilla.mozilla.org/show_bug.cgi?id=1742284
>>>> >
>>>> > https://bugs.chromium.org/p/chromium/issues/detail?id=1272296
>>>> >
>>>> > 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
>>>> >
>>>> >
>>>> >
>>
>> ________________________________
>> The contents of this email and any attachments are confidential and
intended only for the person or entity to whom it is addressed. If you are
not the intended recipient, any use, review, distribution, reproduction or
any action taken in reliance upon this message is strictly prohibited. If
you received this message in error, please immediately notify the sender
and permanently delete all copies of the email and any attachments.
>> Click here for translations of this disclaimer.
>> ________________________________