Open rcoenen opened 1 year ago
Here is an example of the logical outcome of WCAG 2.1 on looped Lottie animations. It seems a little absurd, and I doubt this is the true intention of WCAG.
Hi again @rcoenen, Im just going to post here for transparency on the solution we discussed on slack.
The steps of the solution are :
@media (prefers-reduced-motion: reduce)
is there a timeline on implementing the reduced motion flag to disable auto-play?
Description: The Lottie web player controls are currently apparently not WCAG 2.x compliant.
According to current WCAG 2.1 and WCAG 2.2 (draft) guidelines, animations that auto-start and exceed 5 seconds must have controls that allow users to pause, stop, or hide the animation. You can read more about this guideline on the following link: https://www.w3.org/WAI/WCAG22/Understanding/pause-stop-hide.html.
Please note that a 1 second Lottie animation that auto starts and loops can play in principle infinitely, and as such, exceeds 5 seconds. As such WCAG 2.2.2 seems to demand at minimum a play/pause button for every Lottie animation that both auto starts and loops... 🤔
Currently, the Lottie web player controls for auto-started looping animations only include a progress bar and a play/pause button. This means that users who rely on keyboard navigation cannot control the animation or pause it if it is causing a problem.
Proposal: To ensure that the Lottie web player controls for auto-started looping animations are WCAG 2.x compliant, I propose the following solutions:
Ensuring WCAG 2.x compliance is crucial for convincing stakeholders to use Lottie on the web. Currently, the lack of accessibility compliance is seen as a major concern and can be a reason for stakeholders to avoid using Lottie. Implementing the proposed solutions would make Lottie a more viable option for developers who value accessibility.
Thank you.