- From: Abi James <A.James@soton.ac.uk>
- Date: Fri, 2 Jun 2023 09:11:11 +0000
- To: "Patrick H. Lauke" <redux@splintered.co.uk>
- CC: Chaals Nevile <chaals@fastmail.fm>, "w3c-wai-ig@w3.org" <w3c-wai-ig@w3.org>
I have had the same original query. This situation arises when a control is activated by touch or mouse so it then receives programmatic focus, for example activating a toggle button to menu control. Focus is now on the activated control but it wasn’t moved there by keyboard operation. WCAG 2.4.7 refers specifically applies to keyboard operation but we should be anticipating that people will use a mixture of access modes (e.g. click on a top level menu and then use keys to select an item). Designers query that the focus indicator is displayed when it’s not part of their design and it need careful discussion as often it improves user experience to highlight which control they have just activated. Regards Abi James On 2 Jun 2023, at 09:31, Patrick H. Lauke <redux@splintered.co.uk> wrote: On 02/06/2023 09:17, Chaals Nevile wrote: > > As a mouse user, hover state is actually equivalent to what a keyboard > user gets with focus. This is a deep and tangled mess unfortunately - > and for touchscreens often even worse :( Sure, but in the context of WCAG 2.4.7, we are only talking about the focus state, not the hover state. Whether or not WCAG should also say something about hover state is a different discussion. 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 Friday, 2 June 2023 09:11:22 UTC