[selectors-4] and a11y: pseudo-elements for ::label, ::description, ::active-descendent, etc.

[bradkemper]

It is sometimes difficult to select the right corresponding element that has a significant relationship to another element, if the two elements do not appear in an order that allows the styling of one to be based on the state of the other.

For instance, if author want to style a label based on the validity of an input, they could do something like this:

input:invalid + label { color: red }

...but that only works if the label is after the input, because there is no parent selector or previous sibling selector. However, the UA should know after the parsing the html and before the styling assignment which label is associated with which input, whether through for or aria-labeledby, or by being the parent of the input, or some other mechanism. So I am proposing that the following would work to select that label (or element acting as a label for the input):

input:invalid::label { color: red }

So, ::label is a pseudo-element that selects the labeling element, wherever it exists in the DOM, for the element the pseudo is attached to.

This ::label pseudo could also select certain of label-like elements with the proper defined relationships, such as a <th> that "labels" a <td>.

Similarly, ::description would select the element that the subject was aria-describedby, and ::active-descendent would select the valid aria-activedescendent of the subject (which might not be a DOM descendent, thanks to aria-owns).

[Loirooriol]

Similar proposals for this usecase:

• [css-selectors] Make <label> elements reflect CSS pseudoclasses on associated form element  #397

  label:invalid { color: red }`

• [selectors4] :for selector #1067:

  label:for(:invalid) { color: red }

[bradkemper]

Ah, yes, I see the need has come up before, and been deferred. I think my proposal goes farther, because it includes anything that acts as a label (including those that have mainly been for AT), not just label elements. The state of aria-* is further along than it used to be, with properties that reflect the associations, and being able to set the associations without ID refs (through scripting). So I think we can go further than the original proposals.

I also think the pseudo-element approach works well for selecting the actual elements (and perhaps their descendants), rather than just inserting pseudo-classes for that element into a function.

I also like that this approach is more generally extendable to other aria attributes/properties, like those I mentioned.

[AutoSponge]

APA supports the continued refinement of this idea. It solves a problem for developers.

[bleper]

HTML has a new concept of linked elements, so it might be worth considering including popovers in the proposed pseudo-elements.

[bradkemper]

HTML has a new concept of linked elements, so it might be worth considering including popovers in the proposed pseudo-elements.

Right, that is a good example of one html element referencing another, as these aria mechanisms do, with no good way to select through that reference.

Maybe something like ::popover and ::popover-trigger to select both ways through that relationship.