Re: Focus-appearance terminology

Mike,
Yes, I get that. I was just thinking that the following would do the same thing and align with the related WCAG 2.0 SC 2.4.7:

2.4.7: Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible.

So then: When any keyboard operable user interface control displays a visible focus indicator…

Basically, 2.4.7 makes it clear that a keyboard focus indicator needs to be visible at some points in time, and the new one makes it clear that when that indicator is visible it needs to meet additional criteria. It doesn’t say that it needs to always be visible, just that when it is visible the following need to be met. This isn’t a huge deal, was just trying to see if it helped make it clearer. Apparently not.

I am more concerned about the component/element/thing language.

Thanks,
AWK

Andrew Kirkpatrick
Director, Accessibility
Adobe

akirkpat@adobe.com<mailto:akirkpat@adobe.com>
http://twitter.com/awkawk



From: Michael Gower <michael.gower@ca.ibm.com>
Date: Monday, January 31, 2022 at 2:49 PM
To: Andrew Kirkpatrick <akirkpat@adobe.com>
Cc: Alastair Campbell <acampbell@nomensa.com>, WCAG <w3c-wai-gl@w3.org>, Wilco Fiers <wilco.fiers@deque.com>
Subject: RE: Focus-appearance terminology

> what are the scenarios where the focus isn’t visible that we are allowing in the AA version?

The scenario we were trying to get away from was requiring the item with focus to meet these appearance requirements all the time until another item takes focus. A few scenarios
- the user does something to cause the item with focus to be obscured by something else, such content (that does not take focus) that appears on hover
- the user repositions their viewport, causing the item with focus to no longer be visible; obviously we want that to be okay, but conversely we don't want the author to have the item with focus out of the viewport as it RECEIVES focus. So we need to combine the "when" of the preamble with the final bullet (the item with focus isn't entirely obscured) so that we both ensure the author doesn't hide it AND ensure the user scrolling the page doesn't automatically fail the SC.

That's why we want the preamble construct to be: When [UICs/elements/controls] receive keyboard focus,



Michael Gower
Senior Consultant in Accessibility
IBM Design


1803 Douglas Street, Victoria, BC  V8T 5C3
gowerm@ca.ibm.com
cellular: (250) 661-0098 *  fax: (250) 220-8034



From:        "Andrew Kirkpatrick" <akirkpat@adobe.com>
To:        "Alastair Campbell" <acampbell@nomensa.com>, "Wilco Fiers" <wilco.fiers@deque.com>
Cc:        "WCAG list (w3c-wai-gl@w3.org)" <w3c-wai-gl@w3.org>
Date:        2022/01/31 06:22 AM
Subject:        [EXTERNAL] Re: Focus-appearance terminology
________________________________



> 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. We can get to the same place without creating different terms, which is why I am suggesting ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

> 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.



We can get to the same place without creating different terms, which is why I am suggesting “keyboard operable user interface control”.



And, if we use “When any keyboard operable user interface control displays a visible focus indicator, the focus indicator meets the following:” then we aren’t saying that it has to be shown at all times.



The issue that I’m trying to avoid is creating additional terms to refer to user interface controls. If we need to constrain the SC to not include all UIC then we should use language that we already have in place to do so.



Related to the AA/AAA difference, I thought that the main distinction was to increase the contrast ratio, change the minimum area, and strengthen the obscured part – what are the scenarios where the focus isn’t visible that we are allowing in the AA version?



Thanks,

AWK





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://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftwitter.com%2Fawkawk&data=04%7C01%7Cakirkpat%40adobe.com%7C896be2319adb4eaf63a908d9e4f2bc9f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637792553466537158%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=zCMzj%2BWPJeMcVMhnBWgAHhg7jKUVI7s3Iuhl2jX7QOU%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 userinterface components<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fw3c.github.io%2Fwcag%2Fguidelines%2F22%2F%23dfn-user-interface-components&data=04%7C01%7Cakirkpat%40adobe.com%7C896be2319adb4eaf63a908d9e4f2bc9f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637792553466537158%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=TFqiva1FUeW%2FinqzEs2WyoE6S1R2wnuJneL5mFqQ58c%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://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.nomensa.com%2F&data=04%7C01%7Cakirkpat%40adobe.com%7C896be2319adb4eaf63a908d9e4f2bc9f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637792553466537158%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=R7qtcZ27JKuMQi81iTpSV3oUAu4Lm2hZxlE3YNV6QHY%3D&reserved=0>









--

Wilco Fiers

Axe-core & Axe-linter product owner - WCAG 3 Project Manager - Facilitator ACT Task Force