Figure and figcaption – extended alternate text for screen readers?

Alternate text for images

For many years the accepted way of making images accessible for people who can’t see them has been by providing alternative text using the alt attribute on the <img> element. Some years ago I wrote a blog post about alternate text for images giving guidance on how to add alternate text to an image and what text to use according to the purpose of the image.

However, in many websites, including hassellinclusion.com, images are often presented with some caption text to explain to sighted users what the images are showing. This is effectively an alternative text for the image, but apart from the close proximity, there is no ‘programmatic’ linkage between the caption and the image. So screen reader users don’t know for sure that there was a linkage between the two.

This led me to thinking, when we’re considering alternative text, are there occasions where it might be useful to go beyond the alt attribute?

Beyond the alt attribute?

HTML5 introduced another container that could be used for images – the <figure> element. It’s not just for images. It can be used to present other self-contained content – for example a table, or a chart.

There is also an optional accompanying <figcaption> element where content authors can place a caption for the image, or whatever else the <figure> element contains. If used, the <figcaption> element has to be a child element of the <figure> element to ensure that the linkage is maintained.

The intent is that the combination of the two elements together can ‘programmatically’ be represented as a single unit on a page. See the Figure with Optional Caption element page on the Mozilla Developer website.

So if screen readers present the information in the <figure> and <figcaption> elements in a way that makes sense to their users, could this be a good way of providing alternative text in situations where sighted users would benefit from it too?

Let’s find out…

Summary of our findings

Here’s a summary of our findings for those who don’t have time to read all the detail below.

By and large it seems that screen readers have ignored the grouping and labeling possibilities offered by <figure> and <figcaption>. In fact the only screen readers that recognised the linkage were on Windows machines – NVDA with Firefox, when users move directly from image to image: and JAWS with Chrome, when users move through the page using the down arrow key.

So for many screen readers, the presence of a <figcaption> element near an image on a page will still just be treated as adjacent content. It doesn’t improve the accessibility of pages to them, and does not replace the alt attribute. The test results reaffirmed that it’s still important not to leave out the alt attribute on an image as otherwise some screen readers will still voice the filename of the image.

However, it is clear that using <figure> and <figcaption> does not reduce the accessibility of pages that use the combination. This is fortunate as the pattern is used within many WordPress sites when images are inserted into pages with accompanying captions.

Testing <figure> and <figcaption> with screen readers

As with many of my other exploratory posts I’ve set up a figure and figcaption test page with some examples of <figure> and <figcaption>. I’ve also included some examples with aria-labelledby and aria-describedby to see if (and how) they influence screen reader behaviour.

The test page consists of 8 sections – each one has an <img> inside a <figure> element:

1. The <img> element has an alt attribute with some text in it. There is no <figcaption>.
2. The <img> element has an alt attribute with some text in it. A <figcaption> is present, also with some text in it.
3. The <img> element has an empty alt attribute. A <figcaption> is present, with some text in it.
4. The <img> element has no alt attribute. A <figcaption> is present, with some text in it.
5. The <img> element has an alt attribute with some text in it. A <figcaption> is present, with some text in it. The <img> element also has an aria-labelledby attribute which references the <figcaption>.
6. The <img> element has an alt attribute with some text in it. A <figcaption> is present, with some text in it. The <img> element also has an aria-describedby attribute which references the <figcaption>.
7. The <img> element has an empty alt attribute. A <figcaption> is present, with some text in it. The <img> element also has an aria-labelledby attribute which references the <figcaption>.
8. The <img> element has no alt attribute . A <figcaption> is present, with some text in it. The <img> element also has an aria-labelledby attribute which references the <figcaption>.

Examples 3 and 4 are present to see if it’s possible to use the <figcaption> to provide the alternate text instead of the alt attribute. Examples 5, 6, 7, and 8 are present to see if aria attributes can help link the items for screen readers.

Example code

Here is an example of the code used in the test page:

<figure>
  <img src="wembury.jpg" alt="Wembury Beach 2 alternate text" width="200" height="200" />
  <figcaption>Figcaption 2.</figcaption>&nbsp;
</figure>

My testing was carried out on 6 commonly-used combinations of screen reader and browser:

1. NVDA 2018.4.1 and Firefox 65 on Windows 10
2. JAWS 18 and Internet Explorer on Windows 10
3. JAWS 18 and Chrome 73 on Windows 10
4. Voiceover and Safari 12.03 on Mac 10.14 Mojave
5. Talkback with Chrome 73 on Android 8
6. Voiceover with Safari on iOS 11.4

NVDA 2018.4.1 and Firefox 65 on Windows 10

Two modes were tested.

1. Firstly I used the down arrow key to move through the content of the page.
2. Secondly I used the G key to move through the graphics on the page.

Results

This table shows what was announced.

Summary

When using the down arrow, NVDA announced all the <img> elements in turn except for the ones with empty or missing alt attributes. These were just completely ignored by the screen reader. Using aria-labelledby overrode any alternate text, and using aria-describedby added the ‘description’ into the alternate text. It’s interesting to note that using aria-labelledby also brought images with missing or empty alternate text to the attention of NVDA.

When using the ‘G’ key to move through the graphics on the page – once again the images with empty and missing alternate text were ignored, unless aria-labelledby was present. Where <figcaption> was present on images ‘seen’ by NVDA, the screen reader voiced them as a ‘grouping’ labelling them with the <figcaption> value. The alternate text for the image was also voiced, unless aria-labelledby is being used, in which case the <figcaption> contents were voiced instead.

So with NVDA there is some good news. When users access the images directly with the G key there is a direct reference to the <figcaption>. But it’s not possible to use <figcaption> instead of the alt attribute – unless aria-labelledby is used on the <img> element.

JAWS 18 and Internet Explorer on Windows 10

Two modes were tested.

1. Firstly I used the down arrow key to move through the content of the page.
2. Secondly I used the G key to move through the graphics on the page.

Results

This table shows what was announced.

Summary

With Internet Explorer, JAWS behaves substantially the same as NVDA/Firefox when moving down the page with the arrow key in that all elements are announced in turn.

The images with an empty or missing alt attribute are announced as “blank” rather than being ignored completely, except for image 7 – when an empty alt attribute is present as well as an aria-labelledby attribute. Using aria-labelledby can override the alt attribute in other situations, and aria-describedby doesn’t seem to have any affect.

Using the G key, images 3 and 4 (with missing and empty alt attribute, but no aria-labelledby) are ignored. The <figcaption> element is also effectively ignored, unless it is referred to by aria-labelledby. Once again aria-describedby doesn’t seem to have any affect.

So with JAWS and IE11 there is no real connection between the image and the <figcaption>. It’s also not possible to use <figcaption> instead of the alt attribute – unless the alt attribute is completely absent and an aria-labelledby attribute is used.

JAWS 18 and Chrome 73 on Windows 10

Two modes were tested.

1. Firstly I used the down arrow key to move through the content of the page.
2. Secondly I used the G key to move through the graphics on the page.

Results

This table shows what was announced.

Summary

Chrome offers JAWS users more context than IE11 when they use the down arrow to move through the elements. But bizarrely, not so much context when the G key is used to move between images.

When using the down arrow, the <figure> element is announced as “figure”, and the <figcaption> is referenced to title the figure. Images with empty alt attributes are ignored always. Where no aria-labelledby or aria-describedby attributes are present, a missing alt attribute will cause JAWS to completely ignore the image. Using aria-labelledby will override the alternate text as we’ve come to expect, and where aria-describedby has been used on the <img>, JAWS gets explicit in its keystrokes to get at the text referenced by aria-describedby. However pressing the ‘JAWS key+alt+r ‘ keystroke sadly doesn’t yield any useful announcement.

When using the ‘G’ key, the <figcaption> is effectively ignored unless it’s referred to by an aria-labelledby attribute. So it’s just the alternate text for the image that gets read out. Images with empty alt attribute are ignored always, images with absent alt attribute without the aria-labelledby.

So with JAWS and Chrome there is no real connection between the image and the <figcaption>. It’s also not possible to use <figcaption> instead of the alt attribute – unless the alt attribute is completely absent and an aria-labelledby attribute is present.

Voiceover and Safari 12.03 on Mac 10.14 Mojave

Two modes were tested.

1. Firstly I used the down arrow key to move through the content of the page.
2. Secondly I used the VO (Control+Option) + command + G key combination to move through the graphics on the page.

Results

This table shows what was announced.

Summary

Sadly, it’s plain to see that Voiceover on a Mac doesn’t take any notice of the implied grouping offered by the <figure> element.

The <figcaption> element is only read out when arrowing down the page (as you’d expect) or when the <figcaption> is linked to the image with aria-labelledby.

Voiceover also ignores the aria-describedby on the image.

Talkback with Chrome 73 on Android 8

Two modes were tested.

1. Firstly I swiped right to move through the page – coming across the images in turn.
2. Secondly I placed my finger directly onto each image in turn.

Results

This table shows what was announced.

Summary

Without the use of aria-labelledby or aria-describedby on the <img> element, there is no linkage between the image and the <figcaption>. But those attributes would probably deliver the same result if they were pointing at text that wasn’t necessarily part of the <figcaption>.

Voiceover with Safari on iOS 11.4

Three modes were tested.

1. Firstly I swiped right to move through the page – coming across the images in turn.
2. Secondly I placed my finger directly onto each image in turn.
3. I also used the rotor settings to move from image to image on the page.

Results

This table shows what was announced.

Summary

There was no evidence of any linkage between the image and the <figcaption> without the use of of aria-labelledby or aria-describedby – which of course could reference any other text elements other than the <figcaption>.

What do you think?

We hope these insights are useful to you, and would love to hear your experiences around implementing date controls. Please share your comments below.

Want more?

If this blog has been useful, you might like to sign-up for the Hassell Inclusion newsletter to get more insights like this in your email every month.