[csswg-drafts] [css-image-animation] Conveying role, states, properties to platform AAPIs (#13784)

aardrian has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-image-animation] Conveying role, states, properties to platform AAPIs ==
Reading through [ยง 5. Accessibility Considerations](https://www.w3.org/TR/css-image-animation-1/#a11y) I see these statements:

> Currently, screen readers typically do not chose to announce animated images differently from non-animated images, though this could be implemented if found desirable. Similarly, it is not expected that they would announce paused or playing images any differently, though this could be implemented if found desirable.

Screen readers get their information from the user agent. The user agent does this by using platform accessibility APIs. How UAs convey semantics to platform AAPIs is covered by the [Core-AAM spec](https://www.w3.org/TR/core-aam-1.2/).

In order to ensure screen readers _can_ convey this information, the appropriate states (playing, paused) and property (animated) needs to come from the UA, which needs to be defined through this specification and likely a combination of Core-AAM and [ARIA](https://www.w3.org/TR/wai-aria-1.3/).

As of now, there is no [global property in ARIA](https://w3c.github.io/aria/#global_states) that maps to what this spec currently defines through the [`:animated-image`](https://www.w3.org/TR/css-image-animation-1/#selectordef-animated-image) pseudo-class.

There are also no [global states in ARIA](https://w3c.github.io/aria/#global_states) that map to the property values [`paused`](https://www.w3.org/TR/css-image-animation-1/#valdef-image-animation-paused) / [`stopped`](https://www.w3.org/TR/css-image-animation-1/#valdef-image-animation-stopped) nor [`running`](https://www.w3.org/TR/css-image-animation-1/#valdef-image-animation-running) / [`normal`](https://www.w3.org/TR/css-image-animation-1/#valdef-image-animation-normal).

If we look at [ARIA widget attributes](https://w3c.github.io/aria/#attrs_widgets), the closest one to convey playing or not might be [`aria-pressed`](https://w3c.github.io/aria/#aria-pressed), but that would require the image to be a button unless we redefine `aria-pressed`. It doesn't solve conveying that the image is animated. Trying to hack the exposure of the control type (animated image versus button) using [`aria-roledescription`](https://w3c.github.io/aria/#aria-roledescription) will likely cause confusion (and failure to localize), so that's not an option (IMO). A new widget role can possibly address that as well.

At the risk of speaking on behalf of the ARIA WG, the Core-AAM editors, browser makers, and platform makers, it might be worth scoping a new widget role and/or new ARIA properties so this can be conveyed to users.

That can also get UAs to develop native UIs to let users handle this (I know at least Firefox used to allow `Esc` to stop animated GIFs, so there may still be code in there to resurrect). That would also make voice control easier since they could define a common name (absent one in a spec, maybe via a widget role).

I see no reason to delay native UA controls when the accessibility support must be baked in to this feature from the start.


Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13784 using your GitHub account


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

Received on Thursday, 9 April 2026 22:43:13 UTC