Re: Focus not "obscured" to "overlapped"

Alastair you said:
1. “Obscured” doesn’t define how much opacity would be ok, so theoretically
it could be almost solid (but not quite). I don’t think it would be caught
by 1.4.11 or 2.4.11 because you can just scroll those into view.
Focus-not-obscured is about the visibility as you tab to it.

But, if you tabbed to something that was fully overlapped by something that
is "almost solid (but not quite)" wouldn't that fail  2.4.11 because it starts
off with "When the keyboard focus indicator is visible...." The keyboard
focus would be "visible" when you tabbed to the element but would fail the
contrast requirements of 2.4.11.

*Melanie Philipp, CPACC, WAS | *Director, Services Methodology
| 540-848-5220
Deque Systems - Accessibility for Good
www.deque.com


On Wed, Aug 24, 2022 at 1:03 PM Sheri Byrne Haber <sbyrnehaber@vmware.com>
wrote:

> The reason why I am strongly leaning towards number 2 is I don’t think
> number 1 can be tested in an automated manner.  That shouldn’t be the only
> reason for choosing number 2, but it should be a factor.
>
>
>
> Sheri
>
>
>
> *From:* Alastair Campbell <acampbell@nomensa.com>
> *Sent:* Wednesday, August 24, 2022 10:00 AM
> *To:* Jonathan Avila <jon.avila@levelaccess.com>; WCAG list (
> w3c-wai-gl@w3.org) <w3c-wai-gl@w3.org>
> *Subject:* Re: Focus not "obscured" to "overlapped"
>
>
>
> *⚠** External Email*
>
> Hi Jon,
>
>
>
> I think there’s a choice here between:
>
>
>
>    1. “Obscured” doesn’t define how much opacity would be ok, so
>    theoretically it could be almost solid (but not quite). I don’t think it
>    would be caught by 1.4.11 or 2.4.11 because you can just scroll those into
>    view. Focus-not-obscured is about the visibility as you tab to it.
>    2. “Overlapping” also doesn’t say how much opacity would be ok, but
>    I’d read that as opacity not mattering so you look at the overlap. At AA
>    there can be some overlap, at AAA no overlap. Very transparent things (that
>    are visibly ‘ok’) would fail.
>
>
>
> So, we can close a hole and also catch a few (theoretical) things which
> actually aren’t too bad. Or we can leave the hole and a let a few things
> through that are not very visible.
>
>
>
> If people are not keen then we’ll keep with the status quo.
>
>
>
> Kind regards,
>
>
>
> -Alastair
>
>
>
>
>
> *From: *Jonathan Avila <jon.avila@levelaccess.com>
> *Date: *Wednesday, 24 August 2022 at 14:35
> *To: *WCAG list (w3c-wai-gl@w3.org) <w3c-wai-gl@w3.org>
> *Subject: *RE: Focus not "obscured" to "overlapped"
>
> I would think that overlapping is more strict because things can overlap
> but not be obscured or made opaque and in that case if they overlap and
> have no visual impact then it’s not an issue but yet it could fail.  It
> seems if there is an opacity issue then it would be caught already by SC
> 1.4.11 or 2.4.11.    I’m just hesitant to make such a potentially impactful
> change at the last minute without considering the consequences but I would
> not object if the group believes this is better and safer.
>
>
>
> Jonathan
>
>
>
> *From:* Alastair Campbell <acampbell@nomensa.com>
> *Sent:* Wednesday, August 24, 2022 7:59 AM
> *To:* WCAG list (w3c-wai-gl@w3.org) <w3c-wai-gl@w3.org>
> *Subject:* Focus not "obscured" to "overlapped"
>
>
>
> *CAUTION:* This email originated from outside of the organization. Do not
> click links or open attachments unless you recognize the sender and know
> the content is safe.
>
>
>
> Hi everyone,
>
>
>
> The last (very last, I hope) potentially normative issue on WCAG 2.2 is:
>
> https://github.com/w3c/wcag/issues/2583
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fwcag%2Fissues%2F2583&data=05%7C01%7Csbyrnehaber%40vmware.com%7C484b9bd6b8e94da49e3d08da85f238b2%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637969572633722086%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=w0zTbolMQYStK630FMDWGUQT9K2%2F7uEv2jRMcoEt2KA%3D&reserved=0>
>
>
>
> Summary: Is it leaving a hole that the component/indicator could be behind
> a semi-opaque layer?
>
>
>
> If so, should we change the SC to talk about overlapping instead of
> obscuring?
>
>
>
> E.g. When a <a>user interface component</a> receives keyboard focus, the
> component is not entirely overlapped by author-created content.
>
>
>
> That means opacity doesn’t figure into the scope, if it overlaps it
> overlaps.
>
>
>
> That change is implemented in:
>
> https://github.com/w3c/wcag/pull/2634/files
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fwcag%2Fpull%2F2634%2Ffiles&data=05%7C01%7Csbyrnehaber%40vmware.com%7C484b9bd6b8e94da49e3d08da85f238b2%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637969572633722086%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ONAVFICyYelHG3GSeVk9lJ5%2FT3ovTVlyVw0nCdosvHA%3D&reserved=0>
>
>
>
> Does that work? Any objections?
>
>
>
> -Alastair
>
>
> ------------------------------
>
> *⚠** External Email:* This email originated from outside of the
> organization. Do not click links or open attachments unless you recognize
> the sender.
>