Alternative text for short-form video

[tylersticka]

What problem are you trying to solve?

To provide alternative text for an animated image sequence, you can use the alt attribute:

<img src="clip.gif" alt="Old man yells at cloud">

These days, video is often preferable. The quality is higher, the file size is smaller, and the viewer gains playback controls. You can achieve similar behavior to animated GIFs through a combination of preferences:

<video controls autoplay loop muted playsinline src="clip.mp4"></video>

But there isn't a straightforward replacement for the alt attribute. (This has been the most common point of confusion in response to a talk on modern-day GIF-like animations I presented last year.)

Animated GIFs may or may not be declining in popularity, but this need would also apply to more modern short-form video content (the style popularized by TikTok, YouTube Shorts, etc.). These clips are short in length, often with text-based captions that would make them comparable to a GIF or meme in terms of summarization needs.

What solutions exist today?

Some authors incorrectly assume fallback content will work, but that only applies to browsers that don't support <video>.

Another common suggestion is to use captions and subtitles, but those are comparatively time-consuming to generate, and are intended to accompany the media rather than provide a complete alternative.

The most concise and alt-like current solution is to use aria-label (or aria-description):

<video controls autoplay loop muted playsinline
  aria-label="Old man yells at cloud"
  src="clip.mp4"></video>

But this is only reliable when the controls attribute is present. It may also run afoul of automated translation.

You could replace that with aria-labelledby (or aria-describedby):

<video controls autoplay loop muted playsinline
  aria-labelledby="video-label"
  src="clip.mp4"></video>
<div id="video-label" aria-hidden="true">
  Old man yells at cloud
</div>

But in addition to requiring the controls attribute as before, you now need a separate element with a corresponding ID, and you'll likely need to manage the extra element's visibility somehow.

The simplest solution may be a figure and caption:

<figure>
  <video controls autoplay loop muted playsinline src="clip.mp4"></video>
  <figcaption>Old man yells at cloud</figcaption>
</figure>

But this introduces two new elements, and may require visibility of the caption to be managed.

Some browsers support video in <img> elements:

<img src="clip.mp4" alt="Old man yells at cloud">

But aside from inconsistent support, this requires the author choose between supplying alternative text or providing playback controls.

How would you solve it?

I would include the alt attribute as a feature of <video>:

<video controls autoplay loop muted playsinline
  alt="Old man yells at cloud"
  src="clip.mp4"></video>

For consistency with #6627, this could also apply to individual <source> elements:

<video controls loop muted playsinline>
  <source src="clip.mp4" type="video/mp4"
    alt="Old man yells at cloud" />
</video>

And it would be great for the feature to play nicely with #7954, so there's clarity when alt text applies to poster images versus the media itself.

Anything else?

No response

[extra808]

[tl;dr: use, title, a descendant element, or different attribute instead of adding alt to name <video>.]

I think <video> needs attention but all options should be explored. I think alt should remain exclusive to <img>, authors already mistakenly think it can be used on inline SVGs and others so making it valid just for <video> would add to that confusion.

I think it's best to think about what the element needs as not a text alternative but a programmatic name. For many videos, due to its length and/or complexity, a descriptive transcript is required as a text alternative and the unstructured contents of an attribute cannot accommodate transcripts. (Programmatic associations of longer, structured text alternatives using longdesc was never well-supported but could be helpful if supported by <video> and <audio>; an idea for another time.)

There multiple ways elements are named.

Name from contents

As noted, the descendent nodes in <video> are not used to name them, they're only used as fallback content in user agents that don't support them. But that could change; <canvas> is another replaced element and its descendant nodes do name them.

An argument against making <video> match <canvas> is <canvas> uses the nodes for naming and as fallback content. What makes a good name and what is good fallback content is often in conflict; semantic elements are allowed, even links, but none of those semantics are conveyed when the text is accumulated into the programmatic name.

Name from implicit or explicit element association

Inputs and buttons can be named implicitly using <label> or explicitly using <label for>. I don't think this pattern is a good fit.

Some elements are named by descendant elements, <table> by <caption>, <figure> by <figcaption>, <svg> by <title>. I think this could be a good fit for <video> and <audio>, they already have other descendant elements defined. Using <title> as SVG does is an obvious choice but SVGs also exist as independent documents and it might be better to use a new element instead of sharing <title> with HTML documents. (Such a descendant element could also be useful for <canvas>, to avoid the dual-purpose treatment of its contents; when the element isn't present, the contents could then be used for naming.)

An argument against using a descendant element is it wouldn't fit well with the interesting proposal for naming <source> elements. But that proposal is focused on <picture> and while entirely different <video> and <audio> content could be in different sources, I don't think the dimensions can be changed by the sources and there's much less reason to attempt some kind of art direction.

Name from attribute

<video> is already named by an attribute, title. A title on a <video> names that video in the accessibility tree. title is a global attribute and it's already HTML's way of naming another replaced element, <iframe>.

The problem with title is its display by user agents as a tooltip on hover. Videos don't need a visible label so the fact that it's only displayed on hover is not the issue, it's that visually displaying the video name will often be not desired. Preventing the tooltip on hover by adding pointer-events: none would rarely be acceptable on videos because that would also prevent pointer clicks playing/pausing them.

If there is a proposal to make the title not always display a tooltip, on certain elements or under certain conditions, that would resolve this issue with using it to name <video>. It could also solve naming issues for other elements. In the meantime, users have various means of dismissing the user agent tooltips on videos.

aria-label, aria-labelledby

The article that stated these ARIA attributes used for naming elements only works when <video> has controls is from 2017. Today, Chrome, Firefox, and Safari all use the attributes to name the element whether it has controls or not. This is appropriate because both are global ARIA atributes and <video> elements do not have one of the unnamable ARIA roles.

Roles

WAI-ARIA does not specify a role for <video> which in itself is a problem; it's standard that elements with names should also have roles. Different user agents take different approaches when the element is given a name; Safari calls one with controls "Video playback" and "Empty video playback" without controls. Chrome and Firefox go with the typical fallback role for elements with names but no role, "group" (in Chrome, when there's no controls it's "empty group"). Adding something like aria-roledescription="video" can normalize this across user agents.

Properly resolving how to name <video> (and <audio>) should include establishing a WAI-ARIA role as well.

[DemelzaFeltham]

I had a brief chat with my colleague, @stevefaulkner , we suggest using the title attribute as the source of the acc name for short-form video.

Test case: Video Accessibility Test

The pros:

• Leverages an existing HTML attribute, and honours the first rule
• Aligns with how title is used for iframe
• Works in screen readers (tested in JAWS and NVDA—title is announced, and video is conveyed as role=group)

The cons:

• Unlike iframe, title triggers a tooltip popup
• Uncertainty around whether promoting title usage in this context is ideal

For more complex cases, I am imagining something like a TikTok video containing a recipe or a process, we recommend avoiding title due to the tooltip length. Instead, figure with figcaption or details provides a more structured approach.

[tylersticka]

@DemelzaFeltham This is very helpful, thank you! (I've updated one of my articles with a reference to this comment.)

[eeeps]

I don't really know what I'm doing in VoiceOver, but in my fledgling attempts at a test, it announced <img alt> but not <video title> – until I interacted with the <video>. I was not able to interact with the <video> with the keyboard only, but I could hover it and it would be announced.

https://codepen.io/eeeps/pen/YPzORNP
https://o.img.rodeo/video/upload/v1743112682/screen_recording_bfwizz.mp4

I also tried <video role=img aria-label="[description]">; VoiceOver treated this identically.

There is a high likelihood that I am making a basic error. Can anyone with more VoiceOver experience confirm?

[extra808]

@DemelzaFeltham title on iframe can trigger a tooltip popup also but I've only done it when the cursor is on the frame border (worked in Chrome, Firefox, Safari).

@eeeps Navigating through your 'pen using VoiceOver (macOS 15.3.2, Safari 18.3.1) element-by-element (VO+right arrow), I could navigate to the video and its name was announced. However, using Read All (VO+A), it stopped at the heading before the video.

I think where title fits in the name and description computations is pretty good, if it weren't for the tooltip behavior, it would be easier to advocate for. If authors had a way, likely in CSS, to suggest that user agents not show the tooltip, that would help. pointer-events: none has that effect but as I mentioned, it prevents all pointer interactions on video elements (other elements too, like iframe). If that property had a more specific value that was effectively notooltip, that could do it.