Re: Focus-not obscured

HI Gundula,

I’ve added a suggestion here:
https://github.com/w3c/wcag/pull/3341/files#diff-a1e686474a9da05fc533ce56cd7a154aa4c12cbbf42591ac35b181ea0ea57f84R126

“In recognition of more complex interfaces and user needs there is a note: <cite>Content opened by the user may obscure the component receiving focus</cite>. If the user can bring the item with focus into view using a method without having to navigate back to the user-opened content to dismiss it, this criterion would be passed. For example: keyboard actions that may allow the item with focus to be revealed include:”

Does that help?

-Alastair

From: Niemann, Gundula <gundula.niemann@sap.com>
Date: Tuesday, 7 November 2023 at 11:49
To: Alastair Campbell <acampbell@nomensa.com>
Cc: WCAG 2.x issues list (public-wcag2-issues@w3.org) <public-wcag2-issues@w3.org>
Subject: RE: Focus-not obscured
Hello Alastair,

Sorry for not being clear.

In fact, I feel the sentence in line 126 is hard to understand.
“<p>In recognition of more complex interfaces and user needs, the <cite>Content opened by the user may obscure the component receiving focus</cite> note allows for user-opened content to obscure the item receiving focus, provided the user can bring the item with focus into view using a method that doesn't require navigating back to the user-opened content to dismiss it. For example: keyboard actions that may allow the item with focus to be revealed include:</p>”
It is very long and nested.

My subsequent two remarks were meant as additonal remarks, where the first of these goes into line 126 again.

AC> I wouldn’t say ‘never’, but if something opens over the top and takes focus, it cannot be obscuring focus. Now, it might be that you tab away and then focus gets obscured, but in the initial state it wouldn’t obscure focus because it has focus.

I see we agree.

My last remark was meant to refer to line 129.
Thank you for clarifying.

So, my remaining question is, whether the sentence in line 126 can be worded in a less nested way which also is easier to understand.
Or, whether it can be illustrated somehow with a concrete example as an image.
This would be a different PR, though.

Best regards,
Gundula

From: Alastair Campbell <acampbell@nomensa.com>
Sent: Wednesday, 1 November 2023 16:24
To: Niemann, Gundula <gundula.niemann@sap.com>
Cc: WCAG 2.x issues list (public-wcag2-issues@w3.org) <public-wcag2-issues@w3.org>
Subject: Focus-not obscured

Hi Gundula,

Thanks for your comments on the survey:
https://www.w3.org/2002/09/wbs/35422/wcag2x-backlog1/results#xq53

I was a bit confused about whether the second comment was also to do with line 126?

If not I guess it is a request to re-phrase line 126?

In any case, where you said:
> “User opened content, except for tooltip, usually receives focus (menu, dialog). So it can never obscure the focus.
> Can you please clarify?”

I wouldn’t say ‘never’, but if something opens over the top and takes focus, it cannot be obscuring focus. Now, it might be that you tab away and then focus gets obscured, but in the initial state it wouldn’t obscure focus  because it has focus.

You asked for clarification, but I’m not sure which bit you meant (as it didn’t seem related to line 126).


> "<li>using the <kbd>Escape</kbd> key to dismiss the obscuring content;</li>"
How can a different UI element react on keyboard input than the one which has the focus?

It is fairly common for modals and menus, where pressing esc cancels any open dialogue regardless of whether it has focus or not.

I hope that helps,

-Alastair

--

@alastc / www.nomensa.com<http://www.nomensa.com/>