Re: [csswg-drafts] [css-display-4] Define how reading-flow interacts with focusable display: contents elements. (#9230)

Thanks for the notes! Indeed, I tested in the Canary with the flag turned on.

> By "split" do you mean to find each consecutive subsequence of children and text nodes that are not focusable, and treat them as one focusable group? e.g. for the case of `<div style="display:contents"><div>One</div><div tabindex=0>Two</div>Three</div>` it'd have three items that participate in the tab order, which would be visually indicated by the bounding rectangle of "One", "Two", and "Three"?

Yes, this is correct. It is questionable how those should be exposed to the accessibility tree (I don't know what is the best answer: should we announce those with all the element's content? Only the “area”? Something else?), but from a user's perspective those could look like separate entities, and a user can expect to tab through them separately (but that's subjective, and different users could expect different things; but I don't think we need to have a control over this, given we are covering a misuse case).

> Also, how should we determine the order of them? should all of these dynamically split items be focus-ordered as if they had the same `tabindex` as the `display:contents` parent?

Yes, if there is a `tabindex` present on an element with `display: contents`, all its “areas” should inherit it, but the other focusable elements inside should not (as it works now with the regular nested interactive elements: the parent with tabindex is separate, the children are kept in the normal tabindex order). If there is not `tabindex`, then the tabbing order should follow the reading order (so, could also be controlled by `reading-flow`).

> What do you mean by "with the whitespace"?

```HTML
<a>
    <span tabindex="0"></span>
</a>
```

In the above code, there are two text nodes containing only whitespace: between `<a>` and `<span` and between `</span>` and `</a>`. I imagine that for a browser it would be easier to use one of those nodes as the focusable area.

> Also, why "treat it as an absolutely positioned element"?

This is only for a case like `<a><span tabindex="0"></span></a>` — there are no text nodes between the tags, but, ideally, we'd need to have _something_ that could represent the focus state, ideally with a focus ring over it. As it is not a real element, we need to _somehow_ position it, and given the flow can be anything, the least intrusive way to treat it could be to use the same “placeholder” absolutely positioned elements have in their “static” position. But maybe there are other, better, ways to handle this.


-- 
GitHub Notification of comment by kizu
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9230#issuecomment-2165805170 using your GitHub account


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

Received on Thursday, 13 June 2024 14:15:58 UTC