[csswg-drafts] [css-anchor-position-1][css-display-4] Anchor Positioning and Display Order (#9356)

kizu has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-anchor-position-1][css-display-4] Anchor Positioning and Display Order ==
I was thinking a lot about how anchor positioning can be applied for popovers and tooltips, as well as other cases like [sidenotes](https://meyerweb.com/eric/thoughts/2023/09/12/nuclear-anchored-sidenotes/) .

In a lot of these cases, the popover/sidenote/other content can be positioned absolutely in relation to some anchor, so the sighted user would get an understanding of how these elements are connected.

However, semantically, there is nothing that connects the anchor and the content associated with it, and the reading and tab order would not be correct, following the order in the DOM.

This issue is to discuss if we can somehow approach it and what could be the best way to do it. If there was a different issue that was already discussed, let me know!

Right away, I want to list other places where I found people mentioning the need to cover this aspect of absolute positioning:

- There was an unanswered (from what I found; correct me if I missed it somewhere) [question](https://github.com/w3c/csswg-drafts/issues/7387#issuecomment-1160991881) by @aardrian in the [original visual order issue](https://github.com/w3c/csswg-drafts/issues/7387) by @rachelandrew:
    > Does this only apply in a flex/grid context, and if so, what about absolute positioning and floats?
- There was a pre-anchor-position [issue about a `position: popover`](https://github.com/w3c/csswg-drafts/issues/5699) proposal, where @LeaVerou [mentions](https://github.com/w3c/csswg-drafts/issues/5699#issuecomment-754911719) the need to solve the accessibility issue for this kind of positioning:
    > I would argue solving this is also an accessibility matter, since currently a lot of these solutions break accessibility (tabbing order), with the developer not always making up for it with script.

## My Proposal

Now that we are thinking about providing a way to modify the reading order for flex and grid items via something like `reading-order-items` (https://github.com/w3c/csswg-drafts/issues/8589), what if we would also make a similar method apply for anchor positioning?

My idea is to make the anchor defined by `anchor-default` (and, thus, the implicit anchor defined in HTML via an `anchor` prop) the key to solving the reading/tab order for the absolutely positioned elements.

I think in almost every case, when we position something in relation to a specific anchor, we want the tab order to follow from the anchor to the positioned element and then back to the flow after the anchor.

Can we just do this by default? Do we need to make this opt-in while keeping the default DOM order, similar to how we keep the flex/grid intact? I'd argue for handling this by default and _maybe_ providing a way to opt-out, as there is no fear of compat issues due to anchor positioning being new, and I really think almost all cases where we'd have a default anchor would want this behavior.

## Examples

I went through the [examples presented at TPAC](https://docs.google.com/document/d/185yzaofuMP2p1KK00e2J0cmL8vAxOY3LF7NxhpjveRo/edit) (got the link from [these minutes](https://github.com/w3c/csswg-drafts/issues/9117#issuecomment-1717561849)) and separated all the examples into three groups:

### Purely visual

Some cases for anchor positioning can be used for purely visual purposes, like most of the examples in [my article](https://kizu.dev/anchor-positioning-experiments/), or the positioning of the `::backdrop` with an `outline` to create a “gap” in it.

I don't think there are any reservations for these cases — usually purely visual elements won't have any content to read or tab onto, so the behavior of `anchor-default` won't matter for these.

### Popovers and Tooltips

In most cases, a popover would appear after a click on some button, and a tooltip would appear after hovering or focusing over some element.

<img alt="A screenshot of a tooltip/popover from an editable text toolbar, allowing to choose the color to highlight the text with." width="300" src="https://github.com/w3c/csswg-drafts/assets/177485/7b5f6ca8-9e30-475e-8ff1-998a37e6878a" />

Whenever this happens and a popover/tooltip appears, from a keyboard standpoint, it would be logical for the next tab to land inside the next interactive element inside the popover/tooltip. Same for the reading order: I think it would be logical for it to follow into the popover as if it were placed in the DOM after the anchor element.

Main challenge: how to handle dynamic display and position of the absolutely positioned elements?

We would need to properly handle the case when we're on an element inside that popover, then we dismiss it in some way (from the keyboard or by pressing on the backdrop) — the popover closes either by being removed from the DOM, or by getting `display: none`, or maybe even losing the className that gave it the `position: absolute`, but keeping it in the flow (I can imagine footnotes working this way: we could yoink a footnote and show it as a popover, and put it back when dismissing).

The expected way we'd want this to be handled is for the “focus” to return to the anchor element, even if the association would be lost dynamically (`anchor-default` reassigned/unset).

### Sidenotes

I think this example from @meyerweb's [recent article](https://meyerweb.com/eric/thoughts/2023/09/12/nuclear-anchored-sidenotes/) is a good one to look at: 

![A sidenote next to the main text column, with its number aligned with the referencing number found in the main text column. There is a link present in the sidenote.](https://github.com/w3c/csswg-drafts/assets/177485/d8d2434e-fa19-430a-a61d-4eb1bc14904a)
The sidenote is tightly associated with its reference, and there might be tabbable content inside the sidenote that we would want to access from the keyboard right away.

I think it would be completely logical for the tab order to follow the sidenote.

Reading order (and the whole semantics of the sidenotes — are they `aside`, are they a `description`?) is more uncertain. But as a sighted user, I find that I almost always go right away inside the sidenotes/footnotes, breaking the flow.

I cannot speak for screen reader users, but I imagine it is better to also get the sidenote content immediately after the sidenote in some way, given there would be _some_ way to skip it. People who are more knowledgeable in this matter could weigh in on it — it would be very helpful!

However, this might be a case where the out-out for the following the `anchor-default` could be helpful, as it would allow authors to more precisely control how they should such elements behave. Though, we could argue, that we could still utilize the `anchor-default`, and place the default anchor onto the paragraph in question (while utilizing a custom named anchor for the actual anchor), making it so the reading and tab order would follow after the paragraph.

## Conclusion

I think this is an important issue to think about _now_, so we won't create a case where anchor positioning would ship with subpar accessibility, making it harder to do things right afterward without breaking compat.

I am not an accessibility expert, so I could be incorrect in a lot of my assumptions, and I don't know if that behavior I'm talking about is easily implementable or has other issues to think about — that's why I invite anyone to comment, provide their use cases, and so on.

- - -

cc @tabatkins, @fantasai, @jensimmons 

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9356 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 14 September 2023 08:22:35 UTC