Re: Focus not obscured notes

Just to clarify, Jon. This second note is only going to apply when the content the user has opened entirely obscures the item with focus. So, two things must be in place for this note to be relevant:
1) The user has the ability to open new content that is designed to persist after the user has navigated away from it
2) The content that has been opened by the user fully obscures the item with focus

It's important to note that it is possible to design almost anything that meets scenario 1 such that the item receiving focus will never be obscured. However, in certain interactions where the user has two parallel activities to carry out, the realities of screen size (where due to form factor or magnification) mean some overlap between sections may be a preferred model for many. The gmail interaction where the compose email region floats overtop of the inbox is a good example.  We don’t want to disqualify such designs, but we do want there to be a keyboard method to uncover the item with focus. (Google uses a shortcut key.)

As Alastair mentioned, for most of these, a simple mouse click allows the user to dismiss one section or put the other section in the ‘foreground’ (ie. It is now the section floating over the other one). Where both the mouse and keyboard are constrained to one modality at a time, the item receiving focus should never be obscured.

Mike

From: Jon Avila <jon.avila@levelaccess.com>
Date: Friday, April 21, 2023 at 8:46 AM
To: WCAG list (w3c-wai-gl@w3.org) <w3c-wai-gl@w3.org>
Subject: [EXTERNAL] 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
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd
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>