Discuss handling animated GIFs to meet WCAG 2.1 SC 2.2.2

Description

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?

  • ...

Acceptance Criteria

None

Attachments

3

Activity

Oliver Tacke November 26, 2024 at 9:26 AM

I'll come up with a solution for the conflict with enlarging/shrinking the image in the introductory media section and then update my proof-of-concept accordingly.

Oliver Tacke November 20, 2024 at 2:59 PM

Oh, the introductory image in H5P.Question. Right. That is something that will cause trouble and would need to be considered with or without a button.

Hanna Eide Solstad November 20, 2024 at 2:39 PM

YEs probablt the one inside core. The one used on top of questions.

Oliver Tacke November 8, 2024 at 8:16 AM

Is that planned for H5P.Image? Hope that nothing slipped my attention.

Oh, or are you referring to the image widget inside H5P editor core? That would not be impacted/changed at all by this change. It requires separate code that could behave differently if required.

Hanna Eide Solstad November 8, 2024 at 7:43 AM

Won't that interfer with the zooming in and out?

This comment was left via Slack.

Details

Assignee

Reporter

Priority

Created February 15, 2023 at 8:17 PM
Updated November 26, 2024 at 9:26 AM