Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Linked gallery images are not accessible #13164

Open
thatdevgirl opened this issue Jan 2, 2019 · 5 comments

Comments

Projects
None yet
6 participants
@thatdevgirl
Copy link

commented Jan 2, 2019

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

This comment has been minimized.

Copy link

commented Jan 4, 2019

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 comment has been minimized.

Copy link
Contributor

commented Feb 24, 2019

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

screenshot 2019-02-24 at 16 51 06

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

@afercia afercia added [Type] Bug and removed Needs Testing labels Feb 24, 2019

@gziolo gziolo assigned gziolo and unassigned gziolo Mar 20, 2019

@gziolo

This comment has been minimized.

Copy link
Member

commented Mar 20, 2019

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.

@gziolo gziolo added this to the WordPress 5.x milestone Mar 20, 2019

@afercia

This comment has been minimized.

Copy link
Contributor

commented Mar 20, 2019

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:

Screenshot 2019-03-20 at 16 50 54

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:

Screenshot 2019-03-20 at 16 50 58

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

This comment has been minimized.

Copy link

commented Mar 20, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.