Re: 2.4.7 Focus Visible

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
>> >
>> >
>> >