Re: Focus not obscured notes

Trying to keep the language of SC simple is a real challenge. I don't claim
to be good at it, but

I put your proposed text (not what is in the ps) into
https://hemingwayapp.com and it was at a post-grad level.

I brought it down to a grade 10 level by breaking it into two sentences.  I
think this still reflects the intent.

Content opened by the <em>user</em> should not obscure focusable items. The
opened content can obscure focusable items if the user can close it without
moving keyboard focus (for example, by dismissing with Esc).


I tried to get a simpler answer with ChatGPT but wasn't able to come up
with something satisfactory.

I echo Wilco's point. I do think we really should be finding ways to make
WCAG SC easier to understand.

Mike

On Tue, Apr 25, 2023 at 6:56 AM Alastair Campbell <acampbell@nomensa.com>
wrote:

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


-- 

Mike Gifford, Senior Strategist, CivicActions
Drupal Core Accessibility Maintainer
https://civicactions.com    |  https://accessibility.civicactions.com
http://twitter.com/mgifford |  http://linkedin.com/in/mgifford