- From: Michael Livesey <mike.j.livesey@gmail.com>
- Date: Thu, 13 Jul 2023 20:53:20 +0100
- To: "Patrick H. Lauke" <redux@splintered.co.uk>
- Cc: "w3c-wai-ig@w3.org" <w3c-wai-ig@w3.org>
- Message-ID: <CAJOTQE+Dnk1-CAkmS5R2ySHmet6b10v-K2NFxToYRjVeepcZAQ@mail.gmail.com>
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