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>
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>
> *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
>
>
>
>
>
>
>


-- 
*Wilco Fiers*
Axe-core & Axe-linter product owner - WCAG 3 Project Manager - Facilitator
ACT Task Force