undefined | Better HN

0 pointsmasterphai4mo ago0 comments

One subtle thing worth adding is that display: contents also changes how accessibility trees are constructed. The element is removed from the visual layout and from the accessibility tree in many browsers, so semantics like list grouping, landmarks, or ARIA roles can disappear unless you re-introduce them manually.

That’s why subgrid ends up filling a different niche: you preserve the DOM structure, preserve accessibility semantics, and still let the children participate in the parent’s track sizing. It costs more than contents, but it avoids a lot of the accidental side-effects that show up once you start mixing layout, semantics, and interactivity.

0 comments

paulhebert4mo ago

Yeah this is a good callout. My understanding is that display: contents is not meant to impact the accessibility tree but there is a long and ongoing history of browser bugs that make me not want to use it for elements that have an accessible role

webstrand4mo ago

From my testing, as far as I've been able to tell it no longer has any impact on accessibility. The element itself does not appear in the tree, this makes sense display:contents is non-interactive. But all of the children correctly appear in the accessibility tree as if they did not have that shared parent element. But I am by no means an expert at operating screen readers, do you know of any specific issues with it?

paulhebert3mo ago

The issue is if you do want the element to appear in the tree. If the element has semantic meaning it can mess things up.

Adrian Roselli is an accessibility expert who has done extensive testing and written up his findings: https://adrianroselli.com/2022/07/its-mid-2022-and-browsers-...

j / k navigate · click thread line to collapse