The Flash legacy: sub-par!

In the beginning, trailers were developed by animators using Flash. It is an animation technology that we’ve all seen until it became obsolete, firstly because of the Apple ban of Flash on iPads and then because of the evolution of browsing technology towards HTML5 (to put it simply).

Adobe Animate thereafter replaced Adobe Flash, relying on this technological combination:

– Canvas: to put it simply, it is an image format, like a GIF, but dynamically generated by JavaScript, making it possible to animate it on the fly– for example to showcase a trailer,

– JavaScript, which allows you to listen to the events that are taking place in the browser: a click on a button to mute / unmute the sound, a click to replay the trailer, a click on the video to reach to the advertisement.

Accessibility issues with Animate

The trailers showed the following limitations:

– no subtitles (it’s a problem for our customers who are hearing-impaired or deaf),

– no access to video keyboard controls, and no way to follow through promoted links,

– no access to the contents for a screen reader user (visually impaired or blind customers).

First stage: adding subtitles

This is the easiest issue to deal with: we suggested to integrate subtitles directly into the video stream with the advertising project manager. This even makes more sense now that browsers no longer launch automatically a video if the sound is not muted!

Thus we settled both our primary concern for accessibility and a big technical constraint: people who have not activated the sound have the same information as others.

Second stage: managing keyboard navigation

To enable keyboard navigation, we had to go back and take a look at basic video components:

– a video in MP4 format,

– pictograms in SVG,

– event handlers.

In HTML5 we have the tools to insert a video (using the tag with the same name) and talk to it through JavaScript. There even exists a “media” API that lets you send commands like myvideo.play() to, well, play it; myvideo.muted=true to mute it, etc.

It was therefore simply a matter of putting the pictograms in HTML buttons and associating them with event handlers in JavaScript: upon click then perform the corresponding action.

To simplify keyboard navigation, we also had to make sure that the video object itself could not be focused (in other words that it could not be reached by tabbing on the keyboard).

In addition, we had to add a transparent link over the video: this link being natively focusable, leads to the URL provided by the advertising network.

Third stage: Design for Screen Readers

There were still a few difficulties with screen readers:

– Each button must indicate its function (“Play video audio” / “Play video again”); in order to do this, we used certain attributes that are made for this (aria-label for the button, aria-hidden for the SVG that renders it).

– The link should be made up of text readable by a screen reader, which we visually hide so as not to overload the interface (for the experts, we use an sr-only class from Bootstrap).

Expected benefits and putting the cherry on the cake!

Lastly, we still have to make sure that the frame that contains the trailer itself is well described (that is what is called an iframe, a frame internal to the web page the client is viewing), but as for the rest, the work is done and works:

– The elements can be accessed via the keyboard.

– The items are correctly described for a screen reader.

– Subtitles are systematically inserted.

What we did not suspect when starting this project, is that we would also gain a much more frugal result in terms of bandwidth: in the past, when we inserted a video using the system in place, the Adobe Animate libraries inserted about 246kb (kilobytes) of code, not counting the wrapping HTML. Our new accessible code weighs around 8kb, with everything included.

Based on an average of 18 million trailer views per month, the monthly bandwidth gain is around 4.2TB (terabytes)! And who says bandwidth gain also means carbon footprint reduction.

In the end, our approach was good for both accessibility and —surprise!— for our carbon footprint, which is a big win-win!