Linked gallery images are not accessible

[thatdevgirl]

Describe the bug
On the front-end (published page), a gallery block with linked images is not accessible. Screen readers cannot read the images in a gallery if they are linked.

• All of the linked images in the gallery are listed by the image's file name in the "Links" list. (Tested in Voiceover on Mac).
• All of the linked images in the gallery are read by the screen reader as just "link". (Tested in NVDA on Windows.)

This is happening because the <a> tags in the gallery have not ARIA label or text content. The caption of each image is in the <figure> tag, but outside of the <a> tag:

<figure>
  <a href="URL-OF-IMAGE.JPG">
    <img src="URL-OF-IMAGE.JPG">
  </a>

  <figcaption>CAPTION TEXT</figcaption>
</figure>

Either an aria-label attribute needs to be added to the <img> tag or a title attribute needs to be added to the <a> tag.

To Reproduce
Steps to reproduce the behavior:

1. Go to a page that contains a gallery block with linked images.
2. Read the page with a screen reader, specifically the gallery block.

Expected behavior
The links inside the gallery should be read as understandable text, not the image's URL or "link".

[StommePoes]

Since title attrs getting read out by AT is always a hit or miss, the aria-label on the a makes most sense if the images can't have text added to their alts (I'm assuming no alts because of the existence of the figcaptions, but does this prevent the img src attrs from being read out as some AT are known to do in the lack of alt attr presence? May still need alt="").

[afercia]

This also depends on the browser / screen reader combination used, for example Safari and VoiceOver announce the caption:

Also, when the images don't have an alt text, things get a bit more complicated, as the behavior differs across different browsers / SR combos. Seems Safari and VoiceOver announce the image filename even if there's an empty alt="".

Worth noting in core this was addressed a while ago and I guess Gutenberg should follow the same pattern, see:

Add aria-describedby to improve image/caption relationship
https://core.trac.wordpress.org/ticket/34595

[gziolo]

Worth noting in core this was addressed a while ago, and I guess Gutenberg should follow the same pattern, see:

Add aria-describedby to improve image/caption relationship
https://core.trac.wordpress.org/ticket/34595

Does it mean that the implementation should follow the changes added in the following patch: https://core.trac.wordpress.org/attachment/ticket/34595/34595.patch?
It would translate to aria-describedby added to every img tag and pointing to figcaption which would get a unique id assigned.

[afercia]

Yes, that would help. It's complicated because there are various possible cases: images with or without an alt text. Images with or without link.

Having a description (the figcaption) associated with the image with aria-describedby would help screen readers to announce something in any case. In fact, while the figcaption may be announced as name of the figure element by some screen readers:

Within the figure, a linked image without an alt text would not have any associated text. Screen readers will try to read out the only available thing: the filename:

We'd want to avoid that and try to provide some text.

For the brave ones, here's the fallback mechanism for the Accessible Name and Description Computation: https://www.w3.org/TR/accname-1.1/#mapping_additional_nd_te

Would also appreciate feedback from @joedolson

[joedolson]

In the end, we can't guarantee the provision of an appropriate description, but we can definitely increase the likelihood that an image is paired semantically with its description in some way.

Being consistent between the two editing experiences is beneficial, as well, so user experience is consistent over time.

I feel that if the user has not provided any useful text, we should allow the browser & AT defaults to be used, and stay with file name, not try to provide some other arbitrary text. The file name can provide useful information, though it's far from guaranteed - but any text we provided couldn't be any better than "this image has no alternative or descriptive text", which will never be useful. The user already knows this; it doesn't help them to be told it by something we've chosen instead of the default information.

[ZebulanStanphill]

With #26676 merged, this issue needs to be reopened.

[paaljoachim]

What is the next step for this issue?

[glendaviesnz]

Just checked and this is still an issue with the refactored Gallery block where the images are now nested Image blocks.

[celloexpressions]

@glendaviesnz The gallery block refactor (or another recent change) appears to change the behavior for media library images inserted with no alt attribute. They now get alt"=Image gallery image" on every image. In WordPress 5.8, they retain empty alt attributes. It seems like that is "arbitrary text", which is not helpful as explained above. That may be a slightly different issue than the link discussion here, but seems closely related.

When publishing images, I generally expect that the caption will be associated with the image markup for screen readers, and I only add an alt attribute where there is no caption, or if there is additional information beyond what the caption explains. Is that a reasonable approach? And if so, is an empty alt attribute a better default than arbitrary repeated text?

[glendaviesnz]

Is that a reasonable approach? And if so, is an empty alt attribute a better default than arbitrary repeated text?

I can't remember why that text was added, and think you are correct that it is better to stick with the empty text. I have added a PR for this.

[paaljoachim]

Can we get a status update on this issue.
Thanks!

[Mamaduka]

Hi, @glendaviesnz

Can you confirm that this issue was resolved?

Thanks

[glendaviesnz]

@Mamaduka the gallery images are now just Image blocks, and they behave the same as Image blocks in terms of adding an alt attribute to the img tag if alt text is available. They are still lacking the aria-label attribute as suggested above, but so are stand-alone Image blocks, so I wonder if we should close this issue and open an 'Image block accessibility improvements' one?

[ndiego]

I second that we should close this issue in favor of an 'Image block accessibility improvements' issue.

[joedolson]

The underlying issue hasn't changed at all; but it can be handled by making a fix in the Image block.

Adding aria-label is not the recommendation above, as I see it - it's the suggestion from the original poster, but the recommendation from myself and @afercia is to use aria-describedby, matching the previously fixed implementation, however; the recommended change is using aria-describedby to point to the existing caption if there is a caption. If there is no labeling information at all, we should not insert one; we just need to ensure that if there is labeling information available, it should be associated with the link.

[glendaviesnz]

@joedolson Do you think we could just add the aria-describedby details to this existing Image accessibility issue rather than add a new issue for this?

[joedolson]

@glendaviesnz I'm not sure that's appropriate. That issue is about providing notices to users to help guide them in making good choices; this issue is more about how to output code that makes whatever data is available most useful. To me, those are pretty different aspects, and seem like they would need different handling.

[glendaviesnz]

Closing in favour of #42057. @joedolson feel free to edit the new issue description. @paaljoachim you may want to add this new issue to your Image block tracking issue

[paaljoachim]

Thanks for the headsup @glendaviesnz Glen!