Re: Focus not obscured, and consistent help

Hi Gundula,

The SC was focus-appearance when it included the not-obscured bullet.

I was trying to make the point that this was requested in the issue<https://github.com/w3c/wcag/issues/1304#issuecomment-674261174>: “the SC should require that the focus and the focused element are fully visible”

But the group decided not to go that direction due to feasibility (at AA level).

Kind regards,

-Alastair


From: Niemann, Gundula
Hello Alastair,

to which SC is your citation referring to?
“the SC should require that the focus and the focused element are fully visible”
It clearly mentions both focus and focused element.
So at least in the SC referred to here both should be mentioned.
I understand that was the decision back then.

Best regards,
Gundula


From: Alastair Campbell <acampbell@nomensa.com>
Sent: Montag, 15. August 2022 17:34
To: Niemann, Gundula <gundula.niemann@sap.com>
Cc: WCAG <w3c-wai-gl@w3.org>
Subject: Re: Focus not obscured, and consistent help

Hi Gundula,

The difficulty now is the that current requirement (i.e. for the component at AA level) has been out for wide review, and passed the more recent CFC.

We came to the current wording / requirement 2 years ago (Jun-Aug 2020) based on some detailed discussions of the practical implementations & implications.

We started with “the focus indicator”: https://github.com/w3c/wcag/issues/1145<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fwcag%2Fissues%2F1145&data=05%7C01%7Cgundula.niemann%40sap.com%7C878946c776ea4ebebb2b08da7ed3bd26%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C637961745122177596%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=rWzB3rwY2W3lTxo46OvsIL1HpxITyy2tjlskEB02Ekg%3D&reserved=0>

And had several issues [1] that we worked through, and I found this resolution from the time:
https://github.com/w3c/wcag/issues/1304#issuecomment-680261207<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fwcag%2Fissues%2F1304%23issuecomment-680261207&data=05%7C01%7Cgundula.niemann%40sap.com%7C878946c776ea4ebebb2b08da7ed3bd26%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C637961745122177596%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=yNXMQw0Xxg3UnrIJjRgmmnTnl0%2F44adcYWC6d0dw7nU%3D&reserved=0>
“There is significant evidence that it is not always possible for authors to meet a strict 'fully unobscured' requirement. Therefore that requirement has been kept to the AAA version of Focus Appearance.“
That issue included a request that “the SC should require that the focus and the focused element are fully visible”

I don’t think we should change this requirement at the last minute, given the extended discussions on the same topic previously.

Kind regards,

-Alastair

1] https://github.com/w3c/wcag/issues/1271<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fwcag%2Fissues%2F1271&data=05%7C01%7Cgundula.niemann%40sap.com%7C878946c776ea4ebebb2b08da7ed3bd26%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C637961745122177596%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=haL5n6pu9rgO%2FoWW14eJzd7%2BNDcQP43Iz4c66fFFhec%3D&reserved=0>
https://github.com/w3c/wcag/issues/1291<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fwcag%2Fissues%2F1291&data=05%7C01%7Cgundula.niemann%40sap.com%7C878946c776ea4ebebb2b08da7ed3bd26%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C637961745122177596%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=tHOuAA412SlqhBdtARburxAleAIBghTolBb%2FkIUbZlA%3D&reserved=0>



From: Niemann, Gundula <gundula.niemann@sap.com<mailto:gundula.niemann@sap.com>>
Date: Monday, 15 August 2022 at 15:32
To: Alastair Campbell <acampbell@nomensa.com<mailto:acampbell@nomensa.com>>, Bradley-Montgomery, Rachael <rmontgomery@loc.gov<mailto:rmontgomery@loc.gov>>, WCAG <w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>>
Subject: RE: Focus not obscured, and consistent help
Hello Alastair,

on the focus not obscured minimum and enhanced:
That’s why I suggested to mention both focus indicator and component in the AA as well as in the AAA requirement.
For an outline it might not make much of a difference, but for a focus indicator visualized by an indication along one short site of the UI element, it might make a difference, as I tried to explain below.

On consistent help:
Phone number is a good point, thanks for clarifying.

Best regards,
Gundula


From: Alastair Campbell <acampbell@nomensa.com<mailto:acampbell@nomensa.com>>
Sent: Mittwoch, 10. August 2022 00:11
To: Niemann, Gundula <gundula.niemann@sap.com<mailto:gundula.niemann@sap.com>>; Bradley-Montgomery, Rachael <rmontgomery@loc.gov<mailto:rmontgomery@loc.gov>>; WCAG <w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>>
Subject: Re: Focus not obscured, and consistent help

Hi Gundula,

The difference between the AA and AAA versions of focus-not-obscured is intentional.

At the AA level it specifies the component because, in some scenarios, it is very difficult to ensure that the component and the focus indicator are visible. Sometimes it can get cut-off and the author couldn’t prevent that. I can’t remember the scenarios off-hand, but when they came up we settled on that compromise.

I think it also took that form from when it was combined with the focus-appearance SCs, and trying to keep the AA version reasonable.

I don’t think there would be a problem with changing the AA version to specify the focus-indicator, but it also wouldn’t make much (or any?) difference in practice. If anything, an outline might still be showing even if the component is obscured, so specifying the indicator slightly weakens the requirement.

Regarding consistent help, it isn’t covered by consistent navigation because it is setting the scope to the help items. E.g. a phone number might be in the header, but not in navigation at all.
It is intentionally using a similar approach, but help mechanisms may not be navigation, or part of (another) navigation.

Kind regards,

-Alastair


From: Niemann, Gundula <gundula.niemann@sap.com<mailto:gundula.niemann@sap.com>>
Date: Tuesday, 9 August 2022 at 19:04
To: Bradley-Montgomery, Rachael <rmontgomery@loc.gov<mailto:rmontgomery@loc.gov>>, WCAG <w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>>
Subject: RE: CFC Move WCAG 2.2 to Candidate Recommendation (Revised)
-1

I agree all changes already agreed should be in the WCAG 2.2 CR right away, not in an errata, like Patrick explained.
I agree to Bruce’s suggestion concerning the exception in 3.3.7, the exception should be a full sentence.

My main reason is I have an issue with  2.4.12 Focus Not Obscured (Minimum) and 2.4.13 Focus Not Obscured (Enhanced).
Sorry for not having it spotted earlier.

I feel the wording does not really cover the intention.

It says (emphasized by me to illustrate my point):
Success Criterion 2.4.12 Focus Not Obscured (Minimum)
When a user interface component receives keyboard focus, the component is not entirely hidden due to author-created content.

The intention is, that the focus indicator is at least party visible.
If the indication is realized as a 4 CSS pixel thick line along the shortest side of the minimum bounding box of the unfocused component, for example on its left side, it might be completely hidden if the page is scrolled right, while the component itself might be partly or even fully visible.
This way the focused element cannot be identified.
In the benefit it says:
·         This Success Criterion helps anyone who relies on the keyboard to operate the page by letting them visually determine the component on which keyboard operations will interact at any point in time.
This is only true if not only the component is visible, but also the focus indicator.
I suggest to say
"the focus indicator and the component both are not entirely hidden"


It says (emphasized by me to illustrate my point):
Success Criterion 2.4.13 Focus Not Obscured (Enhanced)
When a user interface component receives keyboard focus, no part of the focus indicator is hidden by author-created content.
In a similar case as above, the focus indicator might be fully visible while the focused component is not visible or only a small part of it is visible. Again, the focused element cannot be identified.
The intent of this requirement says:
The purpose of this Success Criterion is to ensure that a component with keyboard focus is visible. This criterion is closely related to Focus Not Obscured (Minimum)<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fw3c.github.io%2Fwcag%2Funderstanding%2Ffocus-not-obscured.html&data=05%7C01%7Cgundula.niemann%40sap.com%7C878946c776ea4ebebb2b08da7ed3bd26%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C637961745122177596%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=J%2FQOYVC%2BhfjcK6SG%2Fx6ADiI9ttaDQGg0Xi4A3BbawQo%3D&reserved=0> but requires that the whole of the component is visible.
Therefore I suggest to say:
"no part of the focus indicator or the component is hidden"

In addition, I feel the current wording is not symmetric. So I suggested a symmetric wording.


I have another point, which is no reason to -1 though, as I can live with it:
Success Criterion 3.2.6: Consistent Help:
As it requests help to be placed in a consistent manner and it does not request help options to be provided, I (still) feel it is already covered by 3.2.3 Consistent Navigation.
If this is not correct, it maybe should be explained in the understanding why it is not covered by 3.2.3.
If it is correct, I understand the requirement shall encourage, though not request, to provide help.
Is that right?


Best regards,
Gundula

----------
Dr. Gundula Niemann
SAP PE UX Accessibility
SAP SE



From: Bradley-Montgomery, Rachael <rmontgomery@loc.gov<mailto:rmontgomery@loc.gov>>
Sent: Dienstag, 2. August 2022 16:03
To: WCAG <w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>>
Subject: Re: CFC Move WCAG 2.2 to Candidate Recommendation (Revised)

My apologies, I used the incorrect URI. Please review https://w3c.github.io/wcag/guidelines/22/<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fw3c.github.io%2Fwcag%2Fguidelines%2F22%2F&data=05%7C01%7Cgundula.niemann%40sap.com%7C878946c776ea4ebebb2b08da7ed3bd26%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C637961745122177596%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=8BqAG7gxrBoW6MvprGfeaTwt%2BjgYW6xsI0T2h8hUCB0%3D&reserved=0>

The revised CFC is below.

Call for Consensus – ends Thursday August 11th at 23:59pm Boston time.
The Working Group has approved CFCs for all new normative content in WCAG 2.2 and it is ready to move to Candidate Recommendation.
The draft is at https://w3c.github.io/wcag/guidelines/22/<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fw3c.github.io%2Fwcag%2Fguidelines%2F22%2F&data=05%7C01%7Cgundula.niemann%40sap.com%7C878946c776ea4ebebb2b08da7ed3bd26%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C637961745122177596%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=8BqAG7gxrBoW6MvprGfeaTwt%2BjgYW6xsI0T2h8hUCB0%3D&reserved=0>
If you have concerns about this proposed consensus position that have not been discussed already and feel that those concerns result in you “not being able to live with” this decision, please let the group know before the CFC deadline.