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>
Sent: Mittwoch, 10. August 2022 00:11
To: Niemann, Gundula <gundula.niemann@sap.com>; Bradley-Montgomery, Rachael <rmontgomery@loc.gov>; WCAG <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%7Ce0efbaebb6164ebab0cd08da7a5433da%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C637956799311374476%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=T16riU78%2FOym8jXR2mtRSTFu%2BeniZGtrkGn1VVO0%2FQc%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%7Ce0efbaebb6164ebab0cd08da7a5433da%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C637956799311374476%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=fXGbTTeG6ushEQNKEF3nHBCwQS1OKpHjXX33Fi9gcHg%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%7Ce0efbaebb6164ebab0cd08da7a5433da%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C637956799311374476%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=fXGbTTeG6ushEQNKEF3nHBCwQS1OKpHjXX33Fi9gcHg%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.