Re: 2.4.7 Focus Visible

Perhaps I didn't phrase correctly.

Applying an outline around the actual checkbox is awful UX, who does that?

In order to apply good UX we need to use the onfocus event. This event
cannot return user agent heuristics for focus-visibility setting.

So in order to apply good UX we would need alway use focus not
focus-visible.

https://accessibleit.disability.illinois.edu/courses/aria-intro/slide23.html

Forcing designers to apply appalling outlines around checkboxes is why
focus was disabled in the first place.

On Wednesday, July 12, 2023, Patrick H. Lauke <redux@splintered.co.uk>
wrote:
> On 12/07/2023 22:40, Michael Livesey wrote:
>
>> A lot of statements have been made in this discussion, such as "we can't
add a focus advisory because all browser would fail by default". However,
in actual fact, all browser do fail by default on radio/checkbox controls.
Neither respond to focus-visible, neither respond to keyboard focus
natively.
>
> They do, and they do. https://codepen.io/patrickhlauke/pen/QWJaRMq
>
>> As the below link to accessible IT from Illinois education demonstrates,
we need to apply focus programmatically using events.
>
> That's because the link points to a custom implementation. In the first
two, the JS adds a class to the wrapping <label> element to provide
additional styling. The second two are completely custom ARIA-based
checkboxes, so the scripting is needed to actually make the <div> act like
a checkbox.
>
> 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
>
>

Received on Thursday, 13 July 2023 19:53:26 UTC