Focus not obscured (minimum) and scrolling content into view

[scottaohara]

I was asked about if content fails this SC if a user can use arrow keys to scroll the obscured focusable element into view.

In reviewing the understanding doc, this is allowed, but is specifically scoped to if the obscuring content is opened by the user.

Why is it ok for a user to use arrow keys to scroll the viewport and reveal the obscured element in that specific case - but if the obscuring content was not opened by the user - but could be revealed by scrolling the viewport, that is a failure?

I'm not necessarily trying to challenge this line by filing this issue, but as scrolling the viewport does not advance focus and does reveal the obscured content, if this line is to be maintained, it needs to be enforced with some explicit rational that can be pointed to.

[patrickhlauke]

Indeed, it seems odd that this is allowed for "content opened by the user", but that the same isn't true in general, either.

[bruce-usab]

Discussed on call 4/26. Suggestion is to change to failure example.

[scottaohara]

Some additional info behind why this issue was raised:

• the use case was a non-modal dialog that was opened by default on page load. at certain (smaller) viewport sizes, the non modal dialog can obscure focused elements. scroll padding isn't a viable solution to get this out of the way (and seemed to be what they took away from the doc - though to me that seems scoped to the sticky header/footer ideas), and their point was that it seemed arbitrary that if someone opened the dialog, it'd be fine to scroll the page to reveal the content, but if the dialog was opened by default, that wasn't acceptable.

imo, after hearing the rational on the call today, I think a resolution to this issue might just be a reclarification / minor extension of the rational to why it's ok for the user-opened content vs not for a pre-existing overlaying element to be more overtly stated in/near this section of content:

In recognition of more complex interfaces and user needs there is a note: Content opened by the user may obscure the component receiving focus. If the user can bring the item with focus into view using a method without having to navigate back to the user-opened content to dismiss it, this criterion would be passed. For example, keyboard actions that may allow the item with focus to be revealed include:

[mbgower]

the use case was a non-modal dialog that was opened by default on page load.

Please note that non-modal dialogs, as described, are specifically called out as a potential problem.

Typical types of content that can overlap focused items are sticky footers, sticky headers, and non-modal dialogs

A key motivator for the introduction of Focus Not Obscured was to address the slightly absurd situation where Focus Visible could be met even though an item receiving focus was not visible to any users.

User agents generally do a good job of bringing the item receiving focus into the viewport. But pages were occurring where the author was overriding behaviour so that items receiving focus were not visible in the viewport. The argument for why this did not fail the already existing 2.0 requirement for Focus Visible was that scrolling the page could be considered a mode of operation in the Focus Visible requirement that "Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible."

Focus Not Obscure ensures that where the item receiving focus is not in view as a result of authoring actions, the page is not conforming.

However, as noted in the Understanding document, the working group acknowledged that the author cannot predict all the ways focus may be obscured due to user actions. As well, whereas it is highly confusing to many users to open a page and not see the item with focus; it is not as confusing if, after opening the page, the user performs an action that causes a persistent overlay to appear (such as a chat window). So there are entire sections of the Understanding document covering User-movable and User-opened content.

I am suggesting the following text be added to the user-movable and User-opened sections (additions in bold).

This SC contains a note regarding content that can be repositioned. If users can move content regions, then
they can potentially position the movable content such that it obscures other content that may receive
focus. If the user has caused a change to layout of the page, the assumption is they will be more likely to
understand the cause of the obscured focus. In such a case, the author is only responsible for ensuring that
the movable content in its initial position does not obscure the item receiving focus.

This section only applies to content that the user actively discloses. As with content that has been moved
by the user, the assumption here is that where a user has caused new content to appear, they will have more
context for how an item receiving focus may be affected by their actions. However, content pre-positioned by the
author (such as a sticky footer), or content that appears without direct user initiation, such as system
warnings, must not prevent the item receiving focus from being immediately visible in the viewport. Also,
this note is not intended to apply to disclosures that are by convention non-persistent. As discussed in the
following sub-section, an open dropdown that does not close when no longer focused is not following this
convention.

Please let indicate whether that addresses the concern.

[scottaohara]

as far as i'm concerned, those would give me jump off points to elaborate as needed. so i'd be happy with those updates.

[scottaohara]

Here's a reduced test case of another example that came up:

initial focus is placed in the moveable/minimizable non-modal dialog which appears on load. placement is purposefully centered in the UI to help ensure people notice this diaog and dont' mistake it for other non-modal dialogs that are positioned on the page and to be honest, there is no additional room in the UI to even place the dialog where it wouldn't cover something (various other existing UI elements are not illustrated in the test case).

The dialog is non-modal because a user may need to check content of the primary UI prior to accepting what the dialog says to do. Thus the dialog can be minimized, or moved (simply demoed in the test case by dismissing, or quick docking to left/right of screen)

But, since this is non-modal, a user can also just tab out of the dialog without moving or minimizing. Focus will be seen to go to the top of the UI, and then as the user navigates focus will obviously go behind the dialog they did not dismiss or move out of the way.

The current wording suggests this would still be a failure because this non-modal dialog was not opened by the user.

what i heard from the brief discussion last week, and per your mentioning of "it is highly confusing to many users to open a page and not see the item with focus" - but not being aware of initial focus isn't really the issue(s) i'm coming up against. For instance, this example, where a user is not moving / dismissing a default rendered element, though they have the opportunity to. And because of that, now their focus can be obscured.

[mbgower]

Yes, that would fail the SC language.

This requirement arose to some degree as a result of an unintended consequence of the GDPR regulation. Now, authors are going to have to deal with another regulatory requirement when countries adopt and require WCAG 2.2. Hopefully the unintended consequences of Focus Not Obscured will be less problematic.

There are obviously a number of design decisions that could be made not to obscure other content, including, but not limited to:

1. Don't design the page such that the user's first experience is to be asked about something they cannot perceive due to its being obscured by the ask.
2. If it's important enough that the user needs to deal with it, make the prompt modal, and allow affordances for the user to engage, dismiss, etc. You have essentially done this, but also posit they don't have to deal with it, so have made it non-modal.
   1. If they don't have to deal with it now, make it dismiss on loss of focus and provide an affordance for later.
3. Start with focus on a button that can launch your non-modal. Give the user the option of undertaking whatever is desired here.

Those are just a few options. You've made the dialog movable, so you could also include persistence considerations based on whether the user repositioned it.

Finally, it's worth mentioning that in the supplied example, one may argue it's obvious that if the focus leaves the modal and focus immediately disappears, that the non-modal is covering up the item with focus (and therefore it's obvious to the user they just need to go back and dismiss the modal). However, there are lots of situations like this where items so obscured will not be the very next item in the tab order. It will be a lot less "obvious" both that the non-modal is the problem AND how to dismiss the non-modal when one has tabbed many times since leaving it.

[scottaohara]

there is no additional room in the UI to even place the dialog where it wouldn't cover something (not part of test case).

@mbgower but the options you provide discount the context i provided.

that the modal is covering up the item with focus...
one may argue it's obvious that if the focus leaves the modal and focus immediately disappears

assuming a typo, but to clarify again - non modal. and focus doesn't immediately disappear, it goes to the first link that is visible above the dialog. Again, reduced test case - but the actual UI would have an entire navigation bar and even some other focusable elements prior to the user even having their focus obscured.

[mbgower]

the options you provide discount the context i provided.

Your context seems to be that you want to let the user know some information, and then let them adjust the UI based on that. Why not just be 2 steps, ie.,

1. First-time overlay reads: "This UI can be adjusted. Select the Adjust button to do so now, or trigger later from the main page."
2. Notice goes away, either because Adjust button is hit (and they adjust) or user dismisses the overlay (using either Dismiss mechanism or moving focus elsewhere).

It's a little hard to speak abstractly about this, but I hope you get the point. If not, we can discuss.

We can make edge cases of any requirement where one can say 'failing this is not that big a deal." Think of the case where at a single point in a UI nothing seems to take focus when pressing tab, and every other tab stop seems fine. Probably not a big deal, right? But that doesn't mean the primary purpose of the orginal Focus Visible SC lacks value.

[scottaohara]

so i'm going to try and reel this back in, because what i was specifically looking for here was:

1. does this (second) example fail the SC. You said yes. OK.
2. clarity on why it fails - since the user's initial focus is clear, they are initially focused within a dialog that provides them mechanisms to adjust or minimize/dismiss the dialog - but the user has ignored these features and instead tabbed out of the non-modal dialog, leading to their focus eventually being obscured.

I'm was not looking for recommendations for what can be done to rectify the issue. I already know what will/won't work for the product to rectify the situation. I was looking for rational as to why this scenario is different to a user purposefully invoking a dialog and not moving it, or even if they had moved this dialog but it still obscured focusable elements, those would pass.

These passing examples acknowledge that the user is aware of what they've done, so therefore because of this understanding, any obscured elements are now due to the user's actions.

Where as the second example i brought up is being perceived as similar (which is why i am looking for clarity in how to better distinguish it, if it in fact needs to be distinguished) - in that the user is aware that the dialog is moveable, because that's where they where focus was initially placed. If a user is given the option to move an obscuring element per this use case of being initially focused on the elements to do so, but they don't, how is that not a similar choice to a user invoking a dialog, it obscuring content, and then the user advancing focus to content the dialog they invoked obscures.

Now to again level set: this questioning is not intending to imply the SC (or other) lacks value, or that i don't understand the problem for the primary use cases this SC is trying to solve. But this is a use case i'm facing and i'm looking for ways to explain, not recommendations on how to fix.

Actually, even trying to re-explain this, I've been thinking more about how i would try to rationalize the SC for this scenario - such as "because the dialog is opened by default, a user is unaware of what it might be obscuring. So unlike the examples of where the user invokes the dialog themselves, there the user has the opportunity to review the UI to be aware of what they may obscure. Where as with the initially opened dialog, the user is unaware of focusable elements, and thus why this is an issue." i still think that might be a bit shaky per the exact scenario - but i would feel confident saying that for an instance where the dialog wasn't initially focused with mechanisms to move/dismiss readily available.

anyway.... i do hope that helps clarify, otherwise, i just wasted a ton of time in writing this out instead of talking through it :D