[css-image-animation] Conveying role, states, properties to platform AAPIs

Reading through § 5. Accessibility Considerations 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.

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.

As of now, there is no global property in ARIA that maps to what this spec currently defines through the :animated-image pseudo-class.

There are also no global states in ARIA that map to the property values paused / stopped nor running / normal.

If we look at ARIA widget attributes, the closest one to convey playing or not might be 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 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.