Is there a standard way to provide alt="" text for screen-readers on HTML5 ads / animations?

Question

When creating HTML5 animations, is there a technique that can be used to "synchronize" the alternate text so that screen-readers reads the given element that appears the moment it appears (or triggered by an event / timeline-driven)?

Ideally, something that I could invoke with GSAP (using it as the animation library for my projects).

Or could such a thing just make the screen-reader speak and pause repeatedly too often, ending up sounding more frustrating than actually enhancing the experience of the user? Would I be better off just to paste essentially a "script" of all the animation that is going on, on one line in the alt="..." attribute?

EDIT:

This question is mostly targetted for HTML5 ads - so I'm assuming there has to be a non-invasive way to screen-read the events happening in an animation without requiring the user to actually click the ad to gain focus (which would involuntarily open up the link the ad refers to). At the same time, wouldn't it be some sort of user violation to "force focus" on the ad's dynamic text if the user is in middle of reading an article / only interested to another area of the page? This raises so many other questions!

Breslau

I never used a real screen reader, but according to the fangs screen reader emulator add-on, canvas element are just not supported and the innerHTML of the canvas will be read as normal HTML. So you could just update the canvas.innerHTML to give some alt content. But for how to make the screen-reader knows it has been updated, I have really no experience with it... – Meris

I dont have the experience with GSAP to answer but I would use some JavaScript and add listeners to the various animation events. EG element.addEventListener('animationEnd',function... see developer.mozilla.org/en-US/docs/Web/API/AnimationEvent/… to get you started – Oogonium

maybe see this for the update part, not tested #3671070 – Meris

@Kaiido: Hmm so simply updating the innerHTML won't trigger fangs to re-read it? I'll test and see if that's the case. I can imagine that would be a challenge if it has to be triggered with a hack of some sort. – Breslau

@Kaiido: Ah sorry, just noticed your link now. Will look at that solution to trigger the screen-reader. – Breslau

@bigp, I don't think it can be called a hack, since it is defined in the specs that UA which doesn't support the canvas element should see it as any non supported element and just display it as some sort of a <div>. Don't know if you'll have to set the aria-live attribute on the canvas itself or on an inner element though. – Meris

@Kaiido, sorry wasn't referring to that solution as a hack (didn't read it before I made that statement, thought I'd have to use some sort of polyfill to hook to some special browser events / prevent-default, that sort of thing). It may be simpler than I thought if it's just a matter of changing the content of an element. – Breslau

@Kaiido. (cont) that being said... would this still be the proper approach for say... an HTML5 ad? Would I need to call something along the lines like this first: $("#adDynamicText").focus() to ensure the ad will actually get screen-read while it plays? – Breslau

I'm afraid this would become a "primarly-opinioned-based" question... IMO, for ads, the use of these attributes is somehow "intrusive"... I'm not sure I want to take part of it :-) – Meris

Given that animations are timed and (I assume) the user will have no way to adjust the speed, I'd put aria-hidden="true" on the canvas element, add a visually hidden element that has the pertinent info from the ad, and associate them with aria-describedby. – Daffodil

@Daffodil do some screen readers not treat canvas as an unsupported element? Otherwise, just setting the pertinent info as inner elements would be enough no? – Meris

I assume you want the screenreader user to be able to interact with the ad. Setting aria-live on it will just be annoying and without that if is dynamically updated, screen readers will not pick up the changes which is why I recommended putting the all the relevant content that will appear throughout the animation in the visually hidden element. – Daffodil

Wouldn't this be better suited to closed captions? The alt text should be nothing more than "Advertisement for ____" or "____ animation" or a summary of their contents. – Frontpage

Answer 1

If you create a live region with aria-live like this,

<div role="region" id="announce" aria-live="polite">

And update the content inside with a JavaScript on the right time, screen reader will announce the content whenever it gets updated.

Here's more information on live region.

https://www.w3.org/TR/2008/WD-wai-aria-practices-20080204/#LiveRegions

If you want to hide the content for sited users, you can use this technique.

https://webaim.org/techniques/css/invisiblecontent/

Maybe you can also create a button to turn on/off the announcement, so screen reader users can choose if they want to hear the description in real time or not.

Semicircle

Agreed that aria-live is the best way to have screen readers read new information, but in the code snippet above, role="region" is not necessary. That causes the <div> to become a landmark, which you don't need. – Hannus

Good point. However, I found quite a few examples specifically setting the role as region. Two reasons I could think of... 1. When you set aria-live="polite", sometimes users can miss the announcement when screen reader is reading other information. Then role="region" might be helpful so screen reader users can easily find the particular region through landmark function and review the content manually. 2. Maybe because people call it live region? – Semicircle

A live "region" is rarely an area where you need to navigate to. It's used for announcing things for screen readers. And specifying a role="region" is only half the recipe for making it a landmark. It also needs a label (aria-label or aria-labelledby). See w3.org/TR/wai-aria-1.1/#region, "Authors MUST give each element with role region a brief label that describes the purpose of the content in the region" and "[A region is] sufficiently important that users will likely want to be able to navigate to the section easily and to have it listed in a summary of the page" – Hannus