RE: Focus not obscured notes

Alistair, this aspect seems like an extension of SC 1.4.13 except not limited to something appearing on focus/hover but also when the user activates it.  I often run into content like social bars and videos while using browser zoom that is meant to sit on the side of content but for me is present on top of content including interactive content.  So, I agree this is an issue - however, I'm unsure if some of what we are discussing can stray beyond what is in the success criterion text.

Jonathan

From: Alastair Campbell <acampbell@nomensa.com>
Sent: Friday, April 21, 2023 6:44 AM
To: Jon Avila <jon.avila@levelaccess.com>; WCAG list (w3c-wai-gl@w3.org) <w3c-wai-gl@w3.org>
Subject: Re: Focus not obscured notes

Hi Jon,

A few comments after yours:

> if a chat widget is expanded by the user and then that non-modal chat interface blocks keyboard focusable content but also blocks pointer access to the same content then it doesn't seem like a keyboard specific issue - it seems like an issue for everyone.

AC: Yes, but the degree of difficulty of moving your mouse to close to the chat pop-over, and tabbing through (possibly) most of the page to close it are quite different.


> I would expect most users to do that before trying to interact with content behind it.

AC: It is a broader scenario than just chat windows. E.g. in the thread there was the example of the Linkedin message listing, which covers the right-column in many window-widths. For many users that's intended to sit above the other content unless dismissed.


> The third option for a keystroke to move between overlays is also confusing it's not clear what this means or how it might mitigate the situation.

AC: If you are tabbing through links behind the message-listing (for example), a keystroke to either close the listing, or move to the listing (making it more equivalent to mouse usage) would solve the problem. There is a learning issue (how do people know about the keystroke), but it's an improvement that enables that functionality to be done more accessibly.


> So perhaps two important aspects are:

  *   > Whether you need to the disclosed content to interact with the other content simultaneously or

AC: Perhaps, but I think the aspect of whether you can easily close the pop-over content is the most important?



  *   > When you can access interactive content obscured by the disclosure with a pointer but not with the keyboard - for example such as when you can keep the disclosure open and move with the pointer - that provides an advantage to the pointer user but not the keyboard user.

AC: Indeed, but the tabbing around the whole page to get to the 'close' button is the thing that makes it different.

Overall, it seems like things we can discuss for the understanding doc, are you ok with the general principle: "If a user opens something (e.g. a chat window), but the position is not configurable, then there needs to be a method for the user to close it without moving focus."

Kind regards,

-Alastair

--

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