- From: Jon Avila <jon.avila@levelaccess.com>
- Date: Wed, 29 Mar 2023 19:07:40 +0000
- To: "w3c-waI-gl@w3. org" <w3c-wai-gl@w3.org>
- Message-ID: <BL1PR22MB36831145F705AADED22892ACF1899@BL1PR22MB3683.namprd22.prod.outlook.com>
It seems that removing the "adjacent contrast" focus appearance criterion emphasizes the size increase and not contrast of adjacent pixels. I've re-read the minutes from the call and while a 2px size would make it bigger removing the need for adjacent contrast seems to steer folks into size changes without giving any guidance on adjacent contrast. While size is important - adjacent contrast is just as important here. Since we have SC 1.4.11 in play - if we go with this approach it might be worth continuing to emphasize in the understanding document that adjacent contrast is important and still is a requirement under that SC. So, taking both of these SC into account seems like there is still coverage as long as we make sure the understanding document does not dimmish the need for adjacent contrast. Best Regards, Jonathan From: Alastair Campbell <acampbell@nomensa.com> Sent: Tuesday, March 28, 2023 2:16 PM To: w3c-waI-gl@w3. org <w3c-wai-gl@w3.org> Subject: Re: Focus appearance updates Hi everyone, We didn't have quite enough time for the focus-appearance discussion today, but I think it helped to clarify the options. I think we could proceed with the SC 'at risk', with a preferred option, and a fall-back option. Everyone seemed happy with removing the first part of the SC text, so our fallback option now is: When the keyboard focus indicator<https://www.w3.org/TR/WCAG22/#dfn-focus-indicator> is visible, an area of the focus indicator meets all the following: * is at least as large as the area of a 1 CSS pixel<https://www.w3.org/TR/WCAG22/#dfn-css-pixels> thick perimeter<https://www.w3.org/TR/WCAG22/#dfn-perimeter> of the unfocused component or sub-component, or is at least as large as a 4 CSS pixel thick line along the shortest side of the minimum bounding box<https://www.w3.org/TR/WCAG22/#dfn-minimum-bounding-box> of the unfocused component or sub-component, and * has a contrast ratio of at least 3:1 between the same pixels in the focused and unfocused states, and * has a contrast ratio of at least 3:1 against adjacent non-focus-indicator colors, or is no thinner than 2 CSS pixels. (Plus exceptions.) From the discussion of the other potential options, I've updated the document: https://docs.google.com/document/d/1RGQBMvDAhEylflppCAKrF6IW8zjHjqH6DNqXKKzpHyI/edit#<https://docs.google.com/document/d/1RGQBMvDAhEylflppCAKrF6IW8zjHjqH6DNqXKKzpHyI/edit> If we increase the size requirement, it only makes sense if we also remove the "4 times shortest side" metric. (We could logically increase that to 8 times, but I don't that would be feasible/helpful for the cases we were looking at). Also, with the increased size requirement I think we can drop the last (adjacent contrast) bullet entirely. See the lower part of the doc. So the simplest option (readability wise) is: When the keyboard focus indicator<https://www.w3.org/TR/WCAG22/#dfn-focus-indicator> is visible, an area of the focus indicator meets all the following: o is at least as large as the area of a 2 CSS pixel<https://www.w3.org/TR/WCAG22/#dfn-css-pixels> thick perimeter<https://www.w3.org/TR/WCAG22/#dfn-perimeter> of the unfocused component or sub-component, and o has a contrast ratio of at least 3:1 between the same pixels in the focused and unfocused states. (Plus exceptions.) So, proceeding at risk, can anyone not live with the short option? The fallback being very close to the current SC wording. Kind regards, -Alastair -- @alastc / www.nomensa.com<http://www.nomensa.com>
Received on Wednesday, 29 March 2023 19:07:58 UTC