Re: Focus not obscured notes

Hi Wilco,

I can see two routes from here:


  1.  Update the normative text. Last minute, but possible if agreed quickly.

  2.  Take the note approach, clarifying what hidden means in a more dynamic context.

I’m leaning towards 2, as it is basically saying: If the user opened something that obscures other things, and they can close it, that doesn’t count as hidden. Similar to the first note on configurable panels.

On the language, I agree that ‘disclosed’ is a bit misleading, how about:
Where content opened by the <em>user</em> can obscure focusable items, if the user can close that content without moving keyboard focus (for example, by dismissing with Esc) it is not considered to fully obscure the item receiving focus.

-Alastair

PS. I’m really struggling to form an update to the SC text, and anything talking about user-actions opens pretty big loopholes. E.g. “When a <a>user interface component</a> receives keyboard focus, the component is not entirely hidden due to author-created content, unless the obscuring content was opened by the user and can be dismissed without moving focus.”

In which case tabbing down the page might trigger a footer to appear at the bottom of the viewport, and scrolling up could ‘dismiss’ it. But you still can’t see the focused item!


From: Wilco Fiers <wilco.fiers@deque.com>
Date: Tuesday, 25 April 2023 at 11:06
To: Michael Gower <michael.gower@ca.ibm.com>
Cc: Jon Avila <jon.avila@levelaccess.com>, WCAG list (w3c-wai-gl@w3.org) <w3c-wai-gl@w3.org>
Subject: Re: Focus not obscured notes
Hey folks,
The second note describes an exception to the normative text. We cannot add exceptions in notes. If we want this, it has to be normative.

I support the idea of this, but I'm having a difficult time with the proposed language. This is a long and complicated sentence, I'd like us to try and address that. The phrase  "content disclosed by the user" is confusing to me, reading more like user generated content than content revealed after a user action. And then the "reveal the item" part, it took me reading this a dozen times before I released that "item" here means "the obscured content". I think that should be clearer

On Mon, Apr 24, 2023 at 7:00 PM Michael Gower <michael.gower@ca.ibm.com<mailto:michael.gower@ca.ibm.com>> wrote:
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<mailto:jon.avila@levelaccess.com>>
Date: Friday, April 21, 2023 at 8:46 AM
To: WCAG list (w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>) <w3c-wai-gl@w3.org<mailto: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<mailto:acampbell@nomensa.com>>
Sent: Friday, April 21, 2023 6:44 AM
To: Jon Avila <jon.avila@levelaccess.com<mailto:jon.avila@levelaccess.com>>; WCAG list (w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>) <w3c-wai-gl@w3.org<mailto: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/>





--
Wilco Fiers
Axe-core & Axe-linter product owner - WCAG 3 Project Manager - Facilitator ACT Task Force
[cid:BCBD7D4B-677E-4B95-AE3F-60005DBD9EE4]