Re: [csswg-drafts] [selectors] :heading() selector and the accessibility tree (#12412)

> The intent of `headingoffset` is to make it easier for content with heading elements to appear on different pages in different contexts where the appropriate heading level is different; specifically, the heading level as it is presented in the accessibility tree.

This is mostly correct, but there's a subtlety I'd like to clarify. Heading elements have a concept of a level which is currently mapped to their tag name. The accessibility engines in browsers look at the tag name to determine the level exposed to AT APIs. `Headingoffset` alters the concept of the heading level to represent it relative their ancestors' `headingoffset` state. So the point being heading level state is retained in the _element_, and the accessibility tree reads that data to present to AT APIs. The practical effect of this appears as though it is only changing the accessibility tree, but it's changing of the element's state.

> The intent of a `heading()` is to ease adjusting the styling of headings so that its consistent not with the elements used but their heading level in the accessibility tree.

This is less correct. The intent of `heading()` is to ease adjusting the styling of headings so that it is consistent with the elements' internal state. And this is why I needed to address the subtlety above. The Layout Tree will not influence the Accessibility Tree (in this instance) and the Accessibility Tree will not influence the Layout Tree (ever).

> If the intent is to help accessibility tree heading levels and the DOM elements they're based on correspond,

Let's pause on this bit first. The intent is to help introduce capabilities for more structured headings. The accessibility tree is an important and mandatory part of this, but the intent is not to solely improve accessibility tree ergonomics. The sole intent is not to improve accessibility _in general_ (visually differentiated headings is accessibility too!). 

> it should include all the heading levels in that tree, regardless of how they came to be there.

This would be a layering violation, so won't be possible. But that's not a particularly helpful answer, so let's talk less about philosophical purity and more about practical complexity. The accessibility engines of browsers is not always actively running because it adds a performance cost to compute certain things, and so this isn't technically possible. To provide some examples, a `<div role=heading>` will be exposed to the AT as a role of heading, but a `<legend role=heading>` won't. You can add the `role` attribute to any element, and it can be any value, but the computation for which elements can recieve which roles is handled by the accessibility engine code (which again, isn't always executed). So we could make the `:heading` seletor be a shorthand for `h1,h2,h3,h4,h5,h6,[role=heading]` but that would be _wrong_, because that would style elements like `<legend role=heading>`. The alternative is we could always compute the role of an element and expose that in CSS somehow. This is what https://github.com/w3c/csswg-drafts/issues/3596 is tracking, and the discussion there is indicative of the problems there. I'll quote a relevant comment from that thread:

> While I agree that it'd be possible to extract some or all of this logic from the accessibility runtime and insert it into the mainstream runtime, it's a non-trivial amount of work that, so far, no implementor I'm aware of has agreed to take on.


So the TL;DR of all of this is "In addition to theoretical purity, there are additional complexities which makes it difficult (if not impossible) to implement it that way". 

I hope this is helpful, if not let me know if I can clarify anything. Always happy to discuss this further.

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


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

Received on Saturday, 28 June 2025 19:24:19 UTC