Focus not obscured and "author-created content" seems to exclude certain scenarios

[patrickhlauke]

From a recent discussion, it seems that the "author-created content" part of both 2.4.11 Focus Not Obscured (Minimum) (Level AA) and 2.4.12 Focus Not Obscured (Enhanced) (Level AAA) confusingly seem to exempt situations where a control is not actually obscured/covered by other content, but rather where the control is styled/positioned (accidentally or on purpose) to be slightly off-screen.

(of course if it's fully off-screen, and still receives focus, it would already fails 2.4.7 Focus Visible (Level AA))

While it's late (as ever) to change the normative wording, there may be scope to expand on this scenario in the understanding document to say something about this?

[patrickhlauke]

Unless, of course, we don't agree that if a component is, say, half off-screen or something, that 2.4.12 would not fail?

[alastc]

where the control is styled/positioned (accidentally or on purpose) to be slightly off-screen.

Surely that affects everyone? Or is it only happening when zoomed / text-spaced or something?

It wasn't really the intent, which was more about sticky or pop-over content from the author. The edge of the viewport isn't "authored content" so I don't think it would fail focus-not-obscured.

[patrickhlauke]

Surely that affects everyone? Or is it only happening when zoomed / text-spaced or something?

Yes it would affect everyone, but the point is: if the element is partially off-screen when it receives focus, it is partially obscured, so does it technically also fail Focus Not Obscured (Enhanced) or not?

Seems you're suggesting that no, because it's cut off at the edge of the viewport, rather than being obscured by some other content, it doesn't fail the SC. but isn't the end result the same? There's a focusable element, but the element is only partially visible.

[mbgower]

The SC reads (my bolded emphasis): When a user interface component receives keyboard focus, no part of the component is hidden by author-created content.

It is scoped to author-created content, because the author has no control over user agent rendering in some instances.

One such instance is where the user agent does not adequately scroll the page content to bring an item receiving focus entirely within the viewport, unobscured. Imagine a long page of text content where the text flows so that a random line of text at the bottom of the screen is partially "cut off" by the bottom of the viewport. If there is a link on this last line, the user agent will often not reposition (scroll) that text line up, even though it is getting focus, but will show the focus indicator around the visible part of the link text.

The same thing will occur even without a text link. Here is a recording I took off a random website today, showing that after I tab from one card's 'link'("Star says she knew...") to some cards (combinations of text and images) at the bottom of the page, the user agent does not move the cards up enough in the focus order to let them be fully visible in the viewport. At the end of the clip, I move up the viewport to show that is the case.

https://github.com/w3c/wcag/assets/14298245/631d57c2-978d-42e3-8a5c-9c78e71bd596

That first clip actually demonstrates two ways the user agent can obscure. This second clip just tackles one of them independently.

1. I tab to a link.
2. The User agent's invokes its feature of showing the target for the link in the lower left corner of the screen.
3. I tab again to land on a button in the same lower left part of the screen.
4. The user agent does a timed-removal of the prior link's target, so that the button receiving focus is partly obscured by it.

There is no failure because the obscuring of the item receiving focus is not caused by author-generated content.

https://github.com/w3c/wcag/assets/14298245/d7c0d746-690e-4efb-97a8-321393d96671