HTML Video Poster Image: Enable Responsive Images and ALT Text for Poster

[scottjehl]

What is the issue with the HTML Standard?

UPDATED: April 23, 2026

The video element currently offers a single poster attribute, which allows us to load one poster image source. This is limiting when attempting to deliver an appropriate poster image size depending on browsing conditions and art-directed video sources. Additionally, the poster frame itself does not offer a means of describing/exposing the poster image itself in the accessibility tree.

Primary proposed solutions in exploration

In the discussion thread below, two approaches are being explored as potential ways to bring responsive image selection to poster, and make poster accessible:

1. Allowing an img element (and its optional picture element parent) to be valid child elements of the video element, with the child img's currentSrc property acting as a controller for the value of the video poster (overriding the poster attribute when present). The full plan for this proposal is bulleted out here.

<!--basic, common usage for resolution-based switching -->
<video src="video.webm" poster=”video.webp”>
   <img srcset="video-small.webp 500w, video.webp 1000w" sizes="(max-width: 500px) 100vw, 100vw" alt="a description of the poster image here">
</video>

<!--art-directed usage-->
<video src="square-crop.webm" poster=”square-crop.webp”>
       <source media="(min-width: 60em)" src="wide-crop.webm">
       <picture>
         <source srcset="wide-crop.webp" media="(min-width: 60em)">
         <img src="square-crop.webp" alt="a description of the poster image here">
    </picture>
</video>

2. Extend the video and its source element childnodes with new attributes: postersrcset, postersizes, and posteralt, which could be set initially on the video element to provide srcset-style image resolution switching, and on child source elements to override the parent video element's attributes when a source matches. Whether there's good reason to have posteralt on video and source elements or just the video element is debatable.

<!--basic, common usage for resolution-based switching -->
<video src="video.webm" poster=”video.webp” postersrcset="video-small.webp 500w, video.webp 1000w" postersizes="(max-width: 500px) 100vw, 100vw" posteralt="a description of the poster image here">
</video>

<!--art-directed usage-->
<video src="square-crop.webm" poster=”square-crop.webp” posteralt="a description of the poster image here">
       <source media="(min-width: 60em)" src="wide-crop.webm" postersrcset="wide-crop.webp">
</video>

Pros & Cons, In Short

Both options appear roughly comparable in their ability to address the core needs of the issue.

The benefits of approach 1 are that it leans on existing HTML elements and uses composability, and brings some unique control to poster such as the ability to use fetchpriority for posters on LCP elements, and crossorigin and image decoding features that poster cannot currently use. It'll also benefit from any future improvements to the img and picture element.

Approach 2 on the other hand, brings benefits of being less verbose for art-directed use cases: existing video source elements can gain postersrcset attributes to override the poster image and share the existing <source> elements' media attributes. On the other hand, this approach some surface area to two HTML elements' IDL with the addition of 3 new-to-HTML attributes each. Browser implementations for postersrcset, postersizes, and posteralt would need to freshly introduce these concepts to elements, likely by reusing srcset and accessibility helpers from other elements that use these patterns already.

This comment attempts to summarize the pros and cons in more depth.

Thanks!

[scottaohara]

reminder that allowing for this would then make providing alt text for the posters doable, and thus could close #7954

[scottjehl]

This suggestion seems to have positive feedback.

Would patches/implementations be helpful at this point or does the spec need to lead on this behavior?

[annevk]

cc @whatwg/media

[scottjehl]

Curious how folks feel about this one now? I think a child img element (with an optional picture element parent) would give authors a great deal of flexibility in pairing poster images with video sources, and it would work quite a bit like sources already work in video when they override the src attribute (this time for poster).

[johannesodland]

I'm in favor of anything that will allow us to match the poster image with the video source 🚀

The only con I can see is that this will require repeating source elements with the media attribute (and potentially sizes, if srcset is supported for video). I think the added versatility is worth it though.

To see how this could look vs using attributes I'll sketch out two examples below.

With img/picture:

<video loading=lazy>
  <picture>
    <source media="(min-width: 600px)" srcset="...." sizes="auto, 600px"/>
    <img srcset="...." sizes="auto, 100vw" alt="..."/>    
  </picture>
  <source media="(min-width: 600px)" srcset="...." sizes="auto, 600px"/>
  <source srcset="...." sizes="auto, 100vw"/>
</video>

With attributes:

<video loading=lazy>
  <source media="(min-width: 600px)" srcset="...." postersrcset="...." sizes="auto, 600px" sizes="auto, 600px"/>
  <source srcset="...." postersrcset="...." sizes="auto, 100vw" posteralt="..." />
</video>

Note: If poster information is added to the existing video sources, one might need to add more attributes like postertype.

[scottjehl]

Hi all. My team at @Squarespace has begun exploring potential spec revisions, platform tests, and browser implementations with hopes to nudge this idea along. We’re optimistic that adding the ability to use a child <img> element (along with an optional <picture> element wrapper) to control the a <video> element’s poster image would improve the <video> element in several significant ways:

• Accessibility: <video> poster images will be able to be described with alt text, which is not currently possible
• Performance: <img> and <picture> bring a suite of responsive image selection features like srcset and sizes, image format type selection, and media queries
• Developer Control: <img> offers greater control over concerns such as CORS, image decoding, and fetch priority

As we put together a pull request, we wanted to socialize some design decisions we’re thinking about in our initial draft.
Here’s our plan.

• Formalize <img> and <picture> as valid direct child elements of <video> (1–at most–of each), instead of elevating them from the video element’s transparent fallback region. Subsequent <img> or <picture> elements found in a video will be ignored as part of the <video> fallback content.
• Introduce the concept of a “poster controller”, which would refer to the first <img> element descendant of a <video> (excluding descendants of source/track), optionally wrapped in a <picture> so its <source> siblings can contribute to resource selection.
• When a poster controller is present, its resource selection overrides the poster attribute as the source of the poster frame.
• The controller behaves as an ordinary <img> for resource selection, fetching, and accessibility, honoring its own src/srcset/sizes/alt/crossorigin/referrerpolicy/fetchpriority/decoding/loading attributes. Some attributes may be ignored: width, height for example must instead use the <video> element’s layout box.
• The poster controller is exposed in the accessibility tree as a normal <img>, with its alt attribute providing the poster's accessible description. This will be a great addition, as the poster is perceivable content that currently cannot be described in text.
• The poster controller <img> will be hidden from the accessibility tree when it is no longer displayed (eg when the video is playing)
• The controller <img> must not be rendered visibly itself; the <video> paints the controller's currentSrc as its poster frame.
• The <video>'s loading (lazy|eager) attribute, if present, determines how the poster will be fetched by default, but if the poster controller specifies its own loading behavior, that takes precedence for the poster’s fetch specifically. This allows the new standard video[loading=lazy][poster] loading deferral to apply to img-controlled poster requests as it does with poster attributes currently, without needing to apply a duplicate loading=lazy on the <img>. That said, it also affords control over loading the poster eager or lazy independently of the video, if desired.
• The criteria for when to lazy load a poster must be evaluated against the video's layout box (via the document's lazy load intersection observer), even if a controller is used. So in other words, poster will always use the video element’s intersection observer for lazy loading decisions.
• Include steps in the poster-frame algorithm to include handling of mutations to the controller: img/picture child insertion or removal and controller currentSrc changes (on top of element creation and poster attribute changes) should all control the poster’s currentPoster.
• Add an early-return step to the poster-frame algorithm: if a controller exists and its currentSrc is non-empty, use its loaded image (tracking reselection and failures) and skip the poster attribute path.
• Add a readonly video.currentPoster IDL property reflecting the effective poster URL: the controller's currentSrc if a controller is in play; otherwise the parsed poster attribute URL; otherwise the empty string.
• Leave video.poster property unchanged: it should continue to reflect the poster attribute, so authors wanting the effective URL should read video.currentPoster instead.
• Allow preload scanners to speculatively fetch the controller's selected URL like any other img-in-picture, honoring the controller's own loading and related attributes.
• Recommend that UAs defer speculatively fetching the poster attribute URL until the video's end tag, to check for controller presence.
• Add plenty of examples, demonstrating a video with a picture/source poster doing art-directed and density-switched selection, including loading="lazy" deferring on the video's layout box, picture with image source type attribute usage, pairing video orientation (landscape and portrait) with poster image orientations, and more.
• Lastly, note that compatibility for former usage of fallback img elements in video (for browsers that do not support the video element) is designed to play nicely with this change, elevating fallback images to become poster controllers when present.

If you have any questions or thoughts, please feel free to chime in. We’ll be back in touch soon.
Thanks all!

[noamr]

@dalecurtis