Add support for WCAG 2.1 SC 2.2.2: Handling of animated GIFs

[otacke]

The WCAG 2.1 defines a success criterion for pausing/stopping/hiding of moving, blinking, scrolling or auto-updating elements that are not essential (https://www.w3.org/WAI/WCAG21/Understanding/pause-stop-hide). That definition applies to animated GIFs, and the WCAG describes a suggestion for a technique to meet the success criterion (https://www.w3.org/WAI/WCAG21/Techniques/general/G152.html).

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.

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 https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-reduced-motion).

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.

There may be things to discuss, e.g.

• 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 https://www.w3.org/WAI/WCAG21/Techniques/general/G152.html
• 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?
• ...