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

In the meeting I said that I will comment in this issue expanding a bit more on my proposal and the nested interactive elements issues.

1. If an element has `display: contents`, but is **not** focusable, then there are no issues, and its content should participate in the flow as usual, being affected by `reading-flow` etc.
2. Otherwise, if an element has both `display: contents` and **is** focusable, but does not have any other focusable elements inside, this element's content becomes one focusable area. Example: https://codepen.io/kizu/pen/rNgYzVW — currently, only Chrome allows us to focus this link, Firefox and Safari both ignore it, which is bad.
3. If an element that has both `display: contents` and is focusable has one or more other focusable elements inside, my proposal is to _split_  the non-focusable areas (excluding whitespace text nodes) inside that element, making them distinct parts that participate in the tab order in the same way they participate in the `reading-flow`.

    By “Areas” I mean consecutive elements and text nodes. If there are _no_ valid areas other than the nested focusable element, we first see if there is one with the whitespace and use it, otherwise we need to create an empty area at the beginning of that element and treat it as an absolutely positioned element in a static flow.

    Example of the current state for this: https://codepen.io/kizu/pen/gOJXxgy — inner element can be focused by all browsers, but the parent with `display: contents` is only accessible as a single area in Chrome, while Safari and Firefox ignore it.

The third case is the most complicated, but it is also a case which is already considered a bad practice: ideally, authors must not nest interactive/focusable elements inside each other. Some references for this:

Articles by @aardrian related to this:
- https://adrianroselli.com/2016/12/be-wary-of-nesting-roles.html
- https://adrianroselli.com/2022/12/the-411-on-4-1-1.html#BadNest

A `nested-interactive` rule in axe related to this:
- https://dequeuniversity.com/rules/axe/4.9/nested-interactive?application=RuleDescription

While this _is_ a bad practice, we need to guarantee that the users would still be able to access the content in at least _some_ 
way.


-- 
GitHub Notification of comment by kizu
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9230#issuecomment-2165545289 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 12:41:12 UTC