Lighthouse: <iframe> with a corresponding <figcaption> does not need a `title` attribute

Created on 26 Aug 2019  Â·  5Comments  Â·  Source: GoogleChrome/lighthouse

Provide the steps to reproduce

  1. Run LH on e.g. https://v8.dev/blog/10-years

The relevant HTML is the following:

<figure>
  <iframe src="https://www.youtube.com/embed/G0vnrPTuxZA" width="640" height="360" loading="lazy"></iframe>
  <figcaption>A visualization of the V8 code base over time [...].</figcaption>
</figure>

What is the current behavior?

The Lighthouse report includes the following warning:

<frame> or <iframe> elements do not have a title.

What is the expected behavior?

Lighthouse should be smart enough to recognize that the <iframe> has a corresponding non-empty <figcaption>, and that is thus does not need a <title> — similar to how images with a corresponding <figcaption> do not need an alt attribute that duplicates the caption.

Environment Information

  • Affected Channels: DevTools
  • Lighthouse version: 5.1.0
  • Operating System: Linux

Most helpful comment

similar to how images with a corresponding

do not need an alt attribute that duplicates the caption.

I'm not sure if this information is entirely accurate. alt text != caption text.

Here's an example:
image
In this instance, just using alt="George Washington" would probably suffice. Without any alt text the image will just announce "image". Because the user does not have the visual affordance of seeing the caption text is adjacent to the image, it may not be clear to them that the caption necessarily relates to that specific image. Or, depending on how the caption is phrased, it might not be clear what the content of the image is.

In the case of the iframe, I think an untitled iframe will just announce "frame". The user then has to enter a special shortcut to move into the frame and interact with it. Otherwise they bypass it. By adding something like `title="V8 code base YouTube video" the user knows that the iframe contains a video and that it's a YouTube embed (so they know what UI patterns to expect).

All 5 comments

cc accessibility expert @robdodson

Thanks for filing @mathiasbynens! If this is reproducible with just axe, would you mind filing in axe-core? They're better equipped to answer if it's intended and where the fix would actually take place :)

similar to how images with a corresponding

do not need an alt attribute that duplicates the caption.

I'm not sure if this information is entirely accurate. alt text != caption text.

Here's an example:
image
In this instance, just using alt="George Washington" would probably suffice. Without any alt text the image will just announce "image". Because the user does not have the visual affordance of seeing the caption text is adjacent to the image, it may not be clear to them that the caption necessarily relates to that specific image. Or, depending on how the caption is phrased, it might not be clear what the content of the image is.

In the case of the iframe, I think an untitled iframe will just announce "frame". The user then has to enter a special shortcut to move into the frame and interact with it. Otherwise they bypass it. By adding something like `title="V8 code base YouTube video" the user knows that the iframe contains a video and that it's a YouTube embed (so they know what UI patterns to expect).

Thanks for clarifying, Rob! Previously, I always acted based on the following recommendation (which applies to all images on v8.dev):

When an image is immediately preceded or followed by a text alternative and the image and the text alternative are not complex in nature, an empty alt attribute SHOULD be considered as an indication that the image can be safely ignored.

But now it sounds like, in combination with a <figcaption>, an alt should be provided regardless. I stand corrected!

Glad we got it sorted out! Thanks @robdodson and @mathiasbynens!

Was this page helpful?
0 / 5 - 0 ratings