Consider accounting for reduced motion preferences when determining if HTMLVideoElements are eligible for autoplay #9900
Description
What is the issue with the HTML Standard?
In the "Playing the media resource" section, the spec lays out some conditions for when a media element is eligible for autoplay:
A media element is said to be eligible for autoplay when all of the following conditions are met:
- Its can autoplay flag is true.
- Its paused attribute is true.
- It has an autoplay attribute specified.
- Its node document's active sandboxing flag set does not have the sandboxed automatic features browsing context flag set.
- Its node document is allowed to use the "autoplay" feature.
Would it make sense to additionally require something similar to the following?
- If the element is an
HTMLVideoElement, the user has NOT requested the system to minimize motion.
In other words, if the user has reduced motion preferences, an HTMLVideoElement would not be eligible for autoplay, even if it has the autoplay attribute.
I'm aware that browsers have been hesitant to enforce the user's motion preferences on the web for potentially breaking websites that rely on motion for their presentation, and instead expose it as a flag that web developers have to handle. A naive example of a website that would break is a website whose content is initially faded out, but uses CSS keyframes or similar to fade in. If a browser universally disabled all animation in this case, the website's content would never be visibly shown.
However, I think disabling autoplay for HTMLVideoElements if the user requested reduced motion should be a relatively safe change in comparison, to my knowledge anyway. Browser implementations already have nuanced conditions for when any media element is allowed to autoplay, and this would just be a small tweak on top of that. From some quick research:
- Firefox allows users to block all media autoplay through settings
- Webkit allows users to customize which websites can autoplay or not
- Chromium has a nuanced autoplay policy
If this change is OK, I suspect the implementation lift should be low. I have an extremely naive prototype of this in Blink. I didn't test it rigorously yet, and I just realized that the patch accidentally affects HTMLAudioElements, but this seems to be a simple change nevertheless, if browsers wanted it.