You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
From an accessibility perspective, preventing autoplay in a simple way is very attractive!
However, there's already a user agent setting called prefers-reduced-motion that is readable as a css variable and accessible via javascript. In the accessibility community, many of us are trying to encourage developers of media player widgets to look at that variable and - if it is set to "reduce" - refrain from autoplaying any kind of video, audio, animation or similar.
I can come up with a few use cases where users may want to limit autoplay but NOT animations. Eg. users who have limited bandwidth or a very expensive connection, but who need the cognitive hints that animations can provide.
But I guess most users who have activated prefers-reduced-motion also do not want autoplay.
The prefers-reduced-motion preference, so far, is not universally recognized. Perhaps the proposed autoplay setting will spread quicker? If so, that would be great for accessibility (and reduce the need for prefers-reduced-motion).
What do you think? Perhaps I am missing some important differences between the two approaches?
A somewhat more detailed dialogue about this can be found in a recent thread in the W3C Community Slack, in the channel called #nordic-accessibility-group-feedback-standards-legislation
The text was updated successfully, but these errors were encountered:
This spec is more about knowing whether a media element could autoplay, as opposed to allowing or disallowing autoplay.
Maybe it's worth opening an issue against HTML for this, if one doesn't already exist? To amend it to say that if the autoplay attribute is set but prefers-reduced-motion is set to reduced, user agents can ignore the autoplay attribute or something along those lines.
Thanks @gkatsev for the clarification!
I re-read the autoplay policy spec now and got a better understanding of it.
Not sure exactly how these two user settings should relate. Here are two example combinations:
If user settings indicate that autoplay is ON (audio + video), but also that the user prefers-reduced-motion, I guess autoplaying audio is fine but more hesitant about autoplaying video.
If user settings indicate that autoplay is OFF, but prefers-reduced-motion has no value, would it still be ok to let gif animations autoplay? Not obvious to me.
From an accessibility perspective, preventing autoplay in a simple way is very attractive!
However, there's already a user agent setting called
prefers-reduced-motion
that is readable as a css variable and accessible via javascript. In the accessibility community, many of us are trying to encourage developers of media player widgets to look at that variable and - if it is set to "reduce" - refrain from autoplaying any kind of video, audio, animation or similar.I can come up with a few use cases where users may want to limit autoplay but NOT animations. Eg. users who have limited bandwidth or a very expensive connection, but who need the cognitive hints that animations can provide.
But I guess most users who have activated prefers-reduced-motion also do not want autoplay.
The
prefers-reduced-motion
preference, so far, is not universally recognized. Perhaps the proposed autoplay setting will spread quicker? If so, that would be great for accessibility (and reduce the need forprefers-reduced-motion
).What do you think? Perhaps I am missing some important differences between the two approaches?
A somewhat more detailed dialogue about this can be found in a recent thread in the W3C Community Slack, in the channel called #nordic-accessibility-group-feedback-standards-legislation
The text was updated successfully, but these errors were encountered: