RE: 2.4.7 Focus Visible

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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<https://urldefense.com/v3/__https:/bugzilla.mozilla.org/show_bug.cgi?id=1445482*c19__;Iw!!N11eV2iwtfs!qYftzAOdDab41jxag5c3oTw2H2yESQ5fPVrGasHGUsG78Tfpaap9AuVhMRV2kk7tXv3a0cRP1zTcJs3egO7h7es$>, 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://urldefense.com/v3/__https:/bugzilla.mozilla.org/show_bug.cgi?id=1742284__;!!N11eV2iwtfs!qYftzAOdDab41jxag5c3oTw2H2yESQ5fPVrGasHGUsG78Tfpaap9AuVhMRV2kk7tXv3a0cRP1zTcJs3eWEN7Gic$>
>> >
>> > https://bugs.chromium.org/p/chromium/issues/detail?id=1272296<https://urldefense.com/v3/__https:/bugs.chromium.org/p/chromium/issues/detail?id=1272296__;!!N11eV2iwtfs!qYftzAOdDab41jxag5c3oTw2H2yESQ5fPVrGasHGUsG78Tfpaap9AuVhMRV2kk7tXv3a0cRP1zTcJs3e9N6H-f8$>
>> >
>> > P
>> > --
>> > Patrick H. Lauke
>> >
>> > https://www.splintered.co.uk/<https://urldefense.com/v3/__https:/www.splintered.co.uk/__;!!N11eV2iwtfs!qYftzAOdDab41jxag5c3oTw2H2yESQ5fPVrGasHGUsG78Tfpaap9AuVhMRV2kk7tXv3a0cRP1zTcJs3e8xs73Hc$> | https://github.com/patrickhlauke<https://urldefense.com/v3/__https:/github.com/patrickhlauke__;!!N11eV2iwtfs!qYftzAOdDab41jxag5c3oTw2H2yESQ5fPVrGasHGUsG78Tfpaap9AuVhMRV2kk7tXv3a0cRP1zTcJs3e0vdJEdQ$>
>> > https://flickr.com/photos/redux/<https://urldefense.com/v3/__https:/flickr.com/photos/redux/__;!!N11eV2iwtfs!qYftzAOdDab41jxag5c3oTw2H2yESQ5fPVrGasHGUsG78Tfpaap9AuVhMRV2kk7tXv3a0cRP1zTcJs3enDmzFZ0$> | https://www.deviantart.com/redux<https://urldefense.com/v3/__https:/www.deviantart.com/redux__;!!N11eV2iwtfs!qYftzAOdDab41jxag5c3oTw2H2yESQ5fPVrGasHGUsG78Tfpaap9AuVhMRV2kk7tXv3a0cRP1zTcJs3eQuvzpfc$>
>> > https://mastodon.social/@patrick_h_lauke<https://urldefense.com/v3/__https:/mastodon.social/@patrick_h_lauke__;!!N11eV2iwtfs!qYftzAOdDab41jxag5c3oTw2H2yESQ5fPVrGasHGUsG78Tfpaap9AuVhMRV2kk7tXv3a0cRP1zTcJs3eLLg6T00$> | 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.<https://secure.wiley.com/email-disclaimers>
________________________________

Received on Wednesday, 19 July 2023 18:09:41 UTC