Details
Assignee
UnassignedUnassignedReporter
Oliver TackeOliver TackePriority
Medium
Details
Details
Assignee
Unassigned
UnassignedReporter
Oliver Tacke
Oliver TackePriority
Created February 15, 2023 at 8:17 PM
Updated November 26, 2024 at 9:26 AM
Background
The WCAG 2.1 defines a success criterion for pausing/stopping/hiding of moving, blinking, scrolling or auto-updating elements that are not essential ( ). That definition applies to animated GIFs, and the WCAG describes a suggestion for a technique to meet the success criterion ( ).
H5P.Image allows users to upload and display animated GIFs. The responsibility for not using animated GIFs at all could be delegated to the author. Here's a suggestion for direct support, really just a suggestion because some things certainly would require discussion.
Suggestion
There’s a suggestion proposed at . It might not work on all setups, so use h5p-cli when looking over it.
The suggestion presented here will do nothing if
an image is not a GIF,
if a GIF image is not animated (checking function included),
if the user did not actively request reduced motion (see ).
Otherwise, the suggestion will
try to compute a static GIF image as a replacement which may fail for cross-origin reasons or on iOS devices that impose limitations,
use a static
canvas
dressed as an image for screen readers as a replacement for the animated GIF,add a button to toggle between the animated GIF and the static replacement in the upper right corner,
keep the animation off by default, and
add an option to the editor that allows authors to explicitly express that an animated image is essential.
Further discussion
Even if the above is all okay, there will be things worth discussing:
Should this be stricter and not even wait for the
prefers-reduced-motion
query to match?Should the animation start automatically but stop after 5 seconds (restartable using the button) as suggested in
Is the
boolean
override field in the editor that allows authors to explicitly express that an animated GIF is essential in order to bypass the whole shebang necessary?What about images that are not added via H5P.Image but H5P core's image widget? Should this be treated similarly incl. moving some of the new functions here into H5P core and allow content types that make use of the internal widget to use them?
...