[css-pseudo] Add aria-* properties *just for pseudo-elements*?

We've discussed a few times adding a bunch of aria-* properties, analogous to the same-named attributes, but so far have rejected that for a few reasons. (Layering, interaction with AT, etc.)

However, those objections don't, afaict, apply to pseudo-elements, while on the other hand being able to set these attributes on pseudo-elements seems like a useful thing.

There's no layering issue, as you can't set the attributes in the first place. These properties would just be exactly equivalent to what setting the attributes would do, if it were possible to do so.
The AT interaction is already CSS-dependent here, as the very existence of a pseudo-element is CSS-controlled, as is its content and accessible label (via the content property).
As we add more interactive pseudos, like for carousel, it seems likely we'll want to make sure the exact accessibility info is specifiable.

So, I suggest we add a set of aria-* properties, just exactly matching the names and value spaces of all the aria-* attributes (with the exception of using aria-role as the property name corresponding to the role attribute). All the keyword attributes will instead take keywords with the same values; numerics will take numbers; IDREFs will take custom-idents or strings; general string attributes will take a string.

@janewman

Tagging @janewman for any thoughts on this from the AT integration perspective.

Do you have more information on which interactive pseudos are being considered as use cases for something like this, aside from carousels? I'm not currently aware of any other current or proposed CSS pseudos (interactive or static) that would benefit from allowing authors to add custom ARIA, but obviously I'm not aware of every proposal. The reason I'm asking is that there have been interactive pseudo proposals floated (e.g. the interest invoker touch button) that would not benefit from author customization, so I think it'd be a mistake to conflate the possibility of interactive pseudos with a need for custom ARIA in CSS.

Do you also have any examples of where this is the case?

The AT interaction is already CSS-dependent here

Generally content inside CSS pseudos that I'm aware of is either fully driven by the element containing the pseudo (e.g. ::checkmark or ::before/after on a button), or is simple static text/image content (e.g. ::before/after on a static element). Other than carousel, I'm not aware of a proposal for a pseudo element that would have an accessible label defined via content -- could you give an example?

For [aria-]role, most pseudo-elements – and at-rules like page margin boxes – should be none/presentation and there are only very few other values that could ever make any sense, e.g. perhaps button for some of the ones proposed for css-forms. However, these should rather be specified in the respective CSS module, not in a stylesheet.

Overall, it may be better to exclude roles from this proposal (and advance :role() instead #3596). Then, though, it needs to be more explicit about which ARIA attributes and states actually make sense to have as CSS properties for pseudo-elements.

Some use cases we've been thinking about:

1. Horizontal or responsive ::picker(select) → aria-orientation

Scenario: a picker laid out as a single row of swatches or icons, or one that switches between horizontal and vertical at a breakpoint.

Today: the picker is exposed as listbox or menu, both of which default to vertical orientation, and there's nowhere to put aria-orientation.

With ARIA-in-CSS:

select:open::picker(select) {
  display: flex;
  aria-orientation: horizontal; /* proposed */
}

@media (width < 30em) {
  select:open::picker(select) {
    flex-direction: column;
    aria-orientation: vertical; /* proposed */
  }
}

2. `aria-role` on `::before`/`::after` for meaningful icons

Scenario: a meaningful glyph icon, such as a warning sign on a form error, generated with ::before.

Today: authors can set the accessible name of generated content with alt text (content: "⚠" / "Warning"), but can't set its role. The common HTML pattern for a meaningful glyph icon is <span role="img" aria-label="Warning">⚠</span>. (Image content with alt text already gets an image role in Chromium; text glyphs don't.)

With ARIA-in-CSS:

.field-error::before {
  content: "⚠" / "Warning";
  aria-role: img; /* proposed */
}

3. `aria-labelledby` for generated content

Scenario: a localized page where the visible "New" label is translated in the DOM by the site's normal localization pipeline, and the badge icon should use that same string as its accName.

Today: alt text in content can set the accName of generated content (content: url(star.svg) / "New!") or hide it from AT (content: "►" / ""). Alt text can't take the accName from visible text elsewhere in the DOM: it can only pull from attributes on the originating element, via attr().

With ARIA-in-CSS:

<span id="new-label" class="visually-hidden">Nouveau</span>
<article class="product new">…</article>

.product.new::before {
  content: url(star.svg);
  aria-labelledby: new-label; /* proposed; IDREF as custom-ident or string */
}

I’m highly supportive of this and see many use cases for it.

I would propose the following changes:

role instead of aria-role. Yes, the naming is unfortunate, but at this point consistency with the attribute is more important
We need a more CSS-native referencing mechanism, modeled after anchor-name and anchor-scope. I’m proposing one here: https://github.com/webplatformco/project-css-interaction/blob/main/README.md#element-references-ref-scope-and-ref-name

Challenges:

I worry that if these are allowed only on pseudo-elements, it could block the way for ever allowing them on anything else just like what happened with content
Even for pseudo-elements, I can see use cases of referencing regular elements from the pseudo-element. For example, an accordion panel:

details {
	ref-scope: --summary;

	> summary {
		ref-name: --summary;
	}

	&::details-content {
		role: region;
		aria-labelledby: --summary;
	}
}

Presumably the referencing properties could work everywhere, though there are cases where referencing an element affects its own AT (e.g. aria-owns). But in most cases it doesn't, so these could be L2.

That said, I think there are a lot more use cases that would benefit from ARIA in CSS on actual elements. This motivated me to resurrect this proposal I had been noodling on, which is essentially a superset of this.

As I argue in the proposal, I think there is tremendous value in encouraging more CSS-based interactivity instead of seeing these use cases as something to mitigate.

Improving the DX of web a11y and making components lighter and more robust benefits everyone:

Lower friction to make experiences accessible directly translates to more accessible experiences.
Semantics move up a level of abstraction. Today the only unit that can carry ARIA once for all its uses is a JS component; a class, a CSS framework or the UA stylesheet cannot. In CSS, whoever defines a pattern specifies it once, and consumers get it automatically (e.g. by using the class).
Co-location resists drift. The dominant scripted-ARIA failure is state desync; deriving semantics from the same selector that drives presentation makes them a single expression.
Fault tolerance. Scripted ARIA fails whole: In JS any uncaught error breaks the entire file. CSS is fault-tolerant by design. An incorrect declaration is dropped without affecting the rest of the sheet.
Fewer wrappers. Built-in elements are often wrapped in components precisely to encapsulate accessibility logic, which today requires JS. Handling accessibility semantics in CSS lets many of these wrappers become a CSS class on a built-in element, and the decrease in complexity compounds downstream.
Of Web Awesome's 73 components, 39 (53%) could have been a simple CSS class if it weren't for JS syncing state to ARIA (7 of them would also need focusgroup); see the component library audit.

I weighed in at the meeting but I would love to have a breakdown of the usecases beyond the tech that is used above; generated content I generally understand but I see this primarily as other gaps in the platform. I am not opposed to solving this with pseudo elements but someone mentioned allowing it to apply to all elements (not solely psuedo elements) and I would like to keep this scoped to psuedo elements only. There are some scenarios that I do think they point to a need for the introduction of new HTML elements; however, my key desire is an accessible outcome for users in common UI paradigms so I don't want my statements to be viewed as blocking this effort if this will help achieve this for end users.

Minutes from the joint session with ARIA WG

Navigation Menu

Repository navigation

[css-pseudo] Add aria-* properties just for pseudo-elements? #14534

1. Horizontal or responsive ::picker(select) → aria-orientation

2. `aria-role` on `::before`/`::after` for meaningful icons

3. `aria-labelledby` for generated content

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[css-pseudo] Add aria-* properties *just for pseudo-elements*? #14534

Description

Activity

kbabbitt commented on Sep 28, 2026

smhigley commented on Oct 2, 2026

Crissov commented on Oct 3, 2026

davidsgrogan commented on Oct 26, 2026

1. Horizontal or responsive ::picker(select) → aria-orientation

2. aria-role on ::before/::after for meaningful icons

3. aria-labelledby for generated content

LeaVerou commented on Oct 26, 2026

gregwhitworth commented on Oct 26, 2026

fantasai commented on Oct 26, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

[css-pseudo] Add aria-* properties just for pseudo-elements? #14534

2. `aria-role` on `::before`/`::after` for meaningful icons

3. `aria-labelledby` for generated content