- From: Alastair Campbell <acampbell@nomensa.com>
- Date: Mon, 31 Jan 2022 10:27:10 +0000
- To: Andrew Kirkpatrick <akirkpat@adobe.com>, Wilco Fiers <wilco.fiers@deque.com>
- CC: "WCAG list (w3c-wai-gl@w3.org)" <w3c-wai-gl@w3.org>
- Message-ID: <AEE7402C-76AE-4326-811C-E4959C2B6ECF@nomensa.com>
Hi Andrew, The problem we were trying to solve was not scoping it to what “is perceived” as a control, but to what element has the keyboard focus. If “User interface element” = user interface control, that doesn’t solve the problem. Also, “receive” was used to allow for scenarios where the focus indicator changes or is subsequently hidden. The AAA version uses “has” to be stricter. I think that would leave it as: “When any keyboard operable element receives keyboard focus, the focus indicator meets the following:” Or a simpler version: “When any interactive element receives keyboard focus, the focus indicator meets the following:” That eliminates the targeted landmark issue. Cheers, -Alastair From: Andrew Kirkpatrick Wilco, Does a landmark or other target of a skip navigation that receives focus but doesn’t have other keyboard interaction need to show that focus visually? I can see the argument as to why it should (people can more easily tell where they are on the page) but also why it shouldn’t (people will think that they can do something with the focused control). I do think that there is benefit to starting with: <p>When any [thing] has a visible focus indicator, the focus indicator meets the following:</p> (this is also a change to remove the “receive” bit and uses the language from the focus visible SC.) Building on that we could say: <p>When any keyboard operable user interface element has a visible focus indicator, the focus indicator meets the following:</p> Of course, in the definition of User Interface Component is this note: What is meant by "component" or "user interface component" here is also sometimes called "user interface element". I don’t think that “Interactive element” is any different than “keyboard operable user interface element” and therefore not any different from “keyboard operable user interface component” – maybe we just need to add in the “keyboard operable” ahead of “user interface component” to solve this? Thanks, AWK Andrew Kirkpatrick Director, Accessibility Adobe akirkpat@adobe.com<mailto:akirkpat@adobe.com> http://twitter.com/awkawk<https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftwitter.com%2Fawkawk&data=04%7C01%7Cacampbell%40nomensa.com%7C5f6afa41eb88486673cc08d9e46a7e51%7Cebea4ad6fbbf43bd8449c56e26692c35%7C0%7C0%7C637791968323164544%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=xggBRjgk2Q61UfobWCabhv898P9YzSp5R6zpzm22Ffo%3D&reserved=0> From: Wilco Fiers <wilco.fiers@deque.com> Date: Sunday, January 30, 2022 at 6:31 PM To: Alastair Campbell <acampbell@nomensa.com> Cc: WCAG <w3c-wai-gl@w3.org> Subject: Re: Focus-appearance terminology Resent-From: WCAG <w3c-wai-gl@w3.org> Resent-Date: Sunday, January 30, 2022 at 6:29 PM Hey Alastair, I'm glad Andrew raised this. I didn't quite realize what that's doing. We shouldn't make the assumption that everything that's focusable is a user interface component. In particular landmarks are often used as the target of skip links. Changing to component or element as you suggest would mean those are then in scope of the SC. On Fri, Jan 28, 2022 at 5:02 PM Alastair Campbell <acampbell@nomensa.com<mailto:acampbell@nomensa.com>> wrote: Hi everyone, (And particularly Andrew and Bruce who raised this.) We were discussing the start of focus-appearance. The published version is: “When user interface components<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fw3c.github.io%2Fwcag%2Fguidelines%2F22%2F%23dfn-user-interface-components&data=04%7C01%7Cacampbell%40nomensa.com%7C5f6afa41eb88486673cc08d9e46a7e51%7Cebea4ad6fbbf43bd8449c56e26692c35%7C0%7C0%7C637791968323164544%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=jn0Ml78HELDBB5a7SQZnyiSZV3hwZEDLwh5suSHnGi0%3D&reserved=0> receive keyboard focus, an area of the focus indicator meets the following:” The proposed update was: “When components receive keyboard focus, an area of the focus indicator meets the following:” With the note, that was intended to scope it to the underlying component rather than the perceived component. As an alternative, how about borrowing from 4.1.1 and using element: “When elements receive keyboard focus, an area of the focus indicator meets the following:” And then swapping ‘element’ in for component in each subsequent usage. Kind regards, -Alastair -- @alastc / www.nomensa.com<https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.nomensa.com%2F&data=04%7C01%7Cacampbell%40nomensa.com%7C5f6afa41eb88486673cc08d9e46a7e51%7Cebea4ad6fbbf43bd8449c56e26692c35%7C0%7C0%7C637791968323164544%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=sru07Bzgkosm%2BKBbeup%2FGJtTSzrUpK4NmJg3f718a1I%3D&reserved=0> -- Wilco Fiers Axe-core & Axe-linter product owner - WCAG 3 Project Manager - Facilitator ACT Task Force [cid:BCBD7D4B-677E-4B95-AE3F-60005DBD9EE4]
Received on Monday, 31 January 2022 10:27:27 UTC