Re: Focus not "obscured" to "overlapped"

Hi Gundula,

My memory of the reason may be hazy (or perhaps the interpretation of “mode of operation” was hazy??), but we did resolve that sticky headers/footers were not a failure of 2.4.7:
https://www.w3.org/2020/06/02-ag-minutes#item05


Before I finished writing this email we had the WCAG 2.x meeting, and the outcome of that discussion was that:


  *   We should keep the current SC text, but…
  *   We should add something to the understanding document about semi-transparent things that could obscure, and link through to 2.4.11.

I.e. if the focus indicator goes behind authored content that is semi-opaque, that doesn’t fail focus-not-obscured, but should be tested against 2.4.11. (Which would be good motivation to use scroll-padding or similar so it doesn’t overlap!)

-Alastair



From: Niemann, Gundula <gundula.niemann@sap.com>
Date: Friday, 26 August 2022 at 14:25
To: Alastair Campbell <acampbell@nomensa.com>, Melanie Philipp <melanie.philipp@deque.com>
Cc: WCAG list (w3c-wai-gl@w3.org) <w3c-wai-gl@w3.org>
Subject: RE: Focus not "obscured" to "overlapped"
Hello Alastair,

revisiting 2.4.7 Focus Visible, I do not follow the point of scrolling.
It says:
“Mode of operation” accounts for user agents which may not always show a focus indicator, or only show the focus indicator when the keyboard is used. User agents may optimise when the focus indicator is shown, such as only showing it when a keyboard is used. Authors are responsible for providing at least one mode of operation where the focus is visible. In most cases there is only one mode of operation so this success criterion applies.“
So it clearly states that the modes mentioned here refer to how  the user agent works on showing (or not showing) the focus.
By stating there is only one mode in most cases, it excludes scrolling as a mode, as scrolling is very common. By far most pages are larger than the viewport. It also excludes moving content, as moving content is an action, not a mode of operation, and as it is very common.

Best regards,
Gundula




From: Alastair Campbell <acampbell@nomensa.com>
Sent: Mittwoch, 24. August 2022 19:28
To: Melanie Philipp <melanie.philipp@deque.com>
Cc: WCAG list (w3c-wai-gl@w3.org) <w3c-wai-gl@w3.org>
Subject: Re: Focus not "obscured" to "overlapped"

Hi Melanie,

Going back to where the requirement came from, we had a discussion about this scenario for 2.4.7. We decided the overlapping wasn’t covered by 2.4.7 because there is a “mode” where it is visible: scroll down a bit or move the overlapping element.

As 2.4.11 builds on 2.4.7, I don’t see how that would cover it. The focus indicator can meet 2.4.11 and be overlapped by something else. That’s why the focus-obscured SC exists.

Otherwise you’d sometimes to do those size calculations but also take off the overlap, which I don’t think anyone would want!

Kind regards,

-Alastair


From: Melanie Philipp <melanie.philipp@deque.com<mailto:melanie.philipp@deque.com>>
Date: Wednesday, 24 August 2022 at 18:24
To: Sheri Byrne Haber <sbyrnehaber@vmware.com<mailto:sbyrnehaber@vmware.com>>
Cc: Alastair Campbell <acampbell@nomensa.com<mailto:acampbell@nomensa.com>>, Jonathan Avila <jon.avila@levelaccess.com<mailto:jon.avila@levelaccess.com>>, WCAG list (w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>) <w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>>
Subject: 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<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.deque.com%2F&data=05%7C01%7Cgundula.niemann%40sap.com%7Cdd2bc4dd1bd14cb61c5a08da85f62e06%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C637969589639792460%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=wGlPpakUm5blQ14lrX1%2Fp4FlPgTRNNvbbDcy3iu6J4Q%3D&reserved=0>


On Wed, Aug 24, 2022 at 1:03 PM Sheri Byrne Haber <sbyrnehaber@vmware.com<mailto: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<mailto:acampbell@nomensa.com>>
Sent: Wednesday, August 24, 2022 10:00 AM
To: Jonathan Avila <jon.avila@levelaccess.com<mailto:jon.avila@levelaccess.com>>; WCAG list (w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>) <w3c-wai-gl@w3.org<mailto: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<mailto:jon.avila@levelaccess.com>>
Date: Wednesday, 24 August 2022 at 14:35
To: WCAG list (w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>) <w3c-wai-gl@w3.org<mailto: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<mailto:acampbell@nomensa.com>>
Sent: Wednesday, August 24, 2022 7:59 AM
To: WCAG list (w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>) <w3c-wai-gl@w3.org<mailto: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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fwcag%2Fissues%2F2583&data=05%7C01%7Cgundula.niemann%40sap.com%7Cdd2bc4dd1bd14cb61c5a08da85f62e06%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C637969589639949106%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=gFqc1HlbVaW4XNheme8V4XjZlX6gmZ7iJwwOW9TRs1I%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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fwcag%2Fpull%2F2634%2Ffiles&data=05%7C01%7Cgundula.niemann%40sap.com%7Cdd2bc4dd1bd14cb61c5a08da85f62e06%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C637969589639949106%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=UzNyg1rfiBZMTn33ww4uEMFbVo7q5KiDVPSJrg6SS3c%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.