[selectors] :heading() selector and the accessibility tree

[extra808]

@keithamus

#10296

I want to stress that I am of the opinion that aria-level or role=heading should not impact :heading(); they are readily selectable today and I don't think aria should have that dramatic an impact on other selectors.

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.

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.

If the intent is to help accessibility tree heading levels and the DOM elements they're based on correspond, it should include all the heading levels in that tree, regardless of how they came to be there.

[keithamus]

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 #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.