How do you figure?

Introduced in the HTML5 specification (now the HTML Living Standard), the figure and figcaption elements are meant to create a meaningful markup structure that:

• presents content that is relevant to the current document, but not vital to its understanding
• and optionally, though often is presented with a descriptive “caption” or “legend” that provides more context to the primary content of the figure.

The figure element

Often thought of as an element to present images or diagrams with captions, the figure element can represent any sort of flow content (code snippets, quotes, tabular data, audio, video, etc.). The content the figure represents is meant to be referred to from the primary content of the document. The information it represents is not meant to be redundant. A figure should be able to be completely removed from the flow of a document (e.g., web page) without any detriment to the understanding of the primary content.

For example, a document outlining the airspeed velocity of an unladen Swallow may have a section explaining the differences between a South African Swallow vs the European Swallow. Accompanying this content could be a figure showcasing a side by side visual comparison of these birds, so as to compliment the information the document outlines. But if this figure was removed, then LOL who cares?

A figure can be used with or without a figcaption. However, without a caption, or providing the figure element with an accessible name (e.g, with the aria-label attribute), the “figureness” of the content may not be overtly communicated by assistive technology. In some cases, AT may not convey any semantics at all if its given no accessible name.

This is not necessarily a bad thing… as there are unfortunately still many developers - and even those that should know better - that use HTML incorrectly.

For instance:

<h2>My Favorite Movies</h2>
<ul>
  <li>
    <figure>
      <picture>
        <img src=fightclub.jpg alt="">
      </picture>
      <figcaption>Fight Club</figcaption>
    </figure>
  </li>
  <!-- more wrong goes here -->
</ul>

The above is an example of how not to use the figure element. The following will hopefully enlighten you on why.

The figcaption element

A figcaption provides a caption, or legend, to the content the figure represents. The figcaption used to provide the accessible name to the figure element. But this often created overly verbose and redundant content. Figure captions can be rather detailed, in some cases they may even contain entire transcripts if audio or video serves as the primary content of the figure. Having an entire transcript as an accessible name of a figure element was an incredibly horrible experience.

So, figcaption is no longer meant to name its parent figure element… though some browsers may still use it as an accessible name source (as of June 2025). But they’re working on it…

If one needs to name a figure element (and not all need names, mind you), aria-label or aria-labelledby attributes would be a more robust and practical method to do so.

The figcaption may be placed before or after the primary contents of the figure, however it must be a direct child of the figure element.

For instance:

<figure>
  <figcaption>...</figcaption>
  <!-- contents of the figure -->
</figure>

<figure>
  <!-- contents of the figure -->
  <figcaption>...</figcaption>
</figure>

<figure>
  <figcaption>
    <div>
      ...
    </div>
  </figcaption>
  <!-- contents of the figure -->
</figure>

However, the following are invalid per the HTML specification:

<figure>
  <div> <!-- or any other element -->
    <figcaption>...</figcaption>
  </div>
  <!-- content of the figure -->
</figure>

<figure>
  <!-- content of the figure -->
  <div> <!-- or any other element -->
    <figcaption>...</figcaption>
  </div>
</figure>

Should an intervening div really be considered a breakage to the semantic relationship between a figure and its figcaption element? Meh… I’m just relaying the rules, I’m not saying I think this one makes much sense. Anyway…

A figcaption may contain flow content, which categorizes most elements allowed as children of the body element. But, as the element is meant to provide a caption to the figure’s content, brief but description text is preferable. The figcaption should not repeat the content of the figure, or other content within the primary document. And by “should not repeat the content of the figure…” that also means the figcaption is not meant to be used to re-state an image’s alternative text.

A figcaption is not a place to repeat or a substitute for image alternative text

Regarding images used within figures, one of the biggest misunderstandings of using a figcaption is that it can be used in lieu of providing an image/graphic alternative text. I’m going to repeat - if you think it’s OK to use alt="" on your image and then use the figcaption to convey the image’s meaning, you are wrong.

A figcaption is meant to provide a caption or summary to what the figure represents, often relating it back to the document the figure is contained within. It is commonly supposed to convey additional information that may not be directly apparent from just reviewing the content of the figure itself.

For instance, consider a photograph of three people standing in front of a building on a sunny day. The person in the middle is holding a giant pair of scissors.

That’d be a decent description of what people might be able to infer when looking at this hypothetical photograph.

But the caption of this photograph could read: “1996 Ribbon cutting ceremony for the opening of Super Corp USA. From left to right, Donald MacDonald, Sir Robert Cutsalot, and Melody Singer.”

This caption information goes beyond what most people would know from just looking at the photo alone. Thus it wouldn’t be appropriate as simply alternative text - becuase then only those who would read the alt text would have a full understanding of the image. And it wouldn’t serve to have this text be the alt text and the caption - beause that’s redundantly redundant.

“But why not make the image have an empty alt, and then just write the caption once?” you say, with an innocence that is both endearing, and yet tiring as we should all be aware at this point what providing an empty alt means for images…

If an image is given an empty alt, then the image is treated as decorative and hidden from the accessibility tree - and thus assistive technology. This is not news.

If one were to have a figure, containing an image marked as decorative, then any figcaption provided would effectively be describing nothing. Does that make sense?

Let’s look at a non-image example. Here’s a figure that contains a Sass code snippet:

<figure>
  <pre><code>
    $align-list: center, left, right;

    @each $align in $align-list {
      .txt-#{$align} {
        text-align: $align;
      }
    }
  </code></pre>
  <figcaption>
    This use of Sass's <code>@each</code> control directive will compile to 
    three CSS classes; .txt-center, .txt-left, and .txt-right.
  </figcaption>
</figure>

Now, imagine putting an aria-hidden="true" on the pre element that wraps the code snippet. Doing so would remove the ability for screen readers and other assistive technology to parse the content the caption refers to.

That’s what it’s like when putting an empty alt on an image in a figure.

The only time a figcaption can be used to name an image

There is a single scenario where one should be able to rely on a figcaption to name an image. That scenario is when an img serves as the only content of a figure and the image has no alt attribute at all.

The HTML Living Standard states this in the algorithm for determining alterntive text of an image:

1. If the image is a descendant of a figure element that has a child figcaption element, and, ignoring the figcaption element and its descendants, the figure element has no flow content descendants other than inter-element whitespace and the img element, then return the contents of the first such figcaption element.

In reality, this is a portion of the spec that no browser ever actually implemented - that is until this Webkit PR that was merged in June 2025. But for other browsers, at least in this case the image would be exposed as an unnamed image, and one could then infer that the caption at least provides some level of understanding of what the image was meant to convey. I know that’ll get your automated checkers all miffed - finding an image without an alt attribute. This is not the best practice by any means, but at least one can understand the image is present and what the figure’s caption is referring to. Hell, some browsers even allow for AI descriptions of images - so long as someone knows an image is even available.

tldr; stop putting alt="" on images in your figure elements. You’re doing it wrong.

figures and screen readers

This is the part of the blog post where I used to have a bunch of testing results with browsers and screen readers. All this content was outdated. I suggest you check out Adrian Roselli’s more recent (2025) testing results.

The previous content can be found in the following disclosure widget:

<!-- 
  aria-label would need to repeat the content of the figcaption 
  to announce the figure as expected. 
-->
<figure aria-label="Figcaption content here.">
  <!-- figure content -->
  <figcaption>
    Figcaption content here.
  </figcaption>
</figure>

<figure role="figure" aria-label="repeat figcaption content here">
  <!-- figure content. if an image, provide alt text -->
  <figcaption>
    Caption for the figure.
  </figcaption>
</figure>

<!--
  aria-label for macOS VoiceOver + Chrome
  role="figure" for IE11.

  IE11 needs an accessible name (provided by aria-label).
  If not for the fact VO + Chrome doesn't support an
  accessible name from aria-labelledby, that attribute
  would have been preferred / pointed to an ID on 
  the <figcaption>.
-->

The end(ish)

I’m sure this will need to be updated (again) in the future, but for now…

Further reading

The following are additional resources to learn more about figures and figcaptions, the test page / results I used, as well as bugs that have been filed with JAWS and NVDA:

• HTML: The figure element
• HTML: The figcaption element
• HTML Accessibility API Mappings 1.0: figure and figcaption elements, W3C
• HTML5 Accessibility
• HTML5 Doctor: figure and figcaption, (2010)
• HTML5 Accessibility Chops: the figure and figcaption elements, Steve Faulkner (2011)
• ARIA: figure role
• Outdated results: figure and figcaption test page
• JAWS + Chrome bug filed
• NVDA bug to support figures