WordPress.org

Make WordPress Core

Opened 5 months ago

Last modified 5 months ago

#43137 new defect (bug)

Media widgets: Improve the image and gallery previews accessibility

Reported by: afercia Owned by:
Milestone: 5.0 Priority: normal
Severity: normal Version: 4.9
Component: Widgets Keywords: has-screenshots has-patch
Focuses: accessibility Cc:

Description

Context: in the front-end, the image alt attribute must describe the purpose of the image or must be empty if the image is not a key part of the content and is purely decorative.

Instead, in the admin screens we're in an editing context. As a user, while authoring content, I need to know what the image is, regardless if the image has or has not an alternative text.

The image widget preview already does something to always provide some info about the image. When the image has no alternative text, it uses an aria-describedby attribute pointing to a hidden element that contains some info about the image file name:

https://cldup.com/uoRHlQWnmn.jpg

Pretty smart. Without this the image wouldn't provide any useful information to assistive technologies and users wouldn't have any clue what the image is about. It can be improved a bit, as the proper way to give an accessible name to an image is using an aria-label or aria-labelledby attribute, not an aria-describedby attribute.

Instead, the preview of the new gallery widget introduced in WordPress 4.9 always prints out an empty alt attribute alt="" for all the images. Worth reminding images with an empty alt attribute are completely ignored by assistive technologies. When navigating through the preview, the only information provided is the textual content for the "more images" text (it appears only when the gallery contains more than 6 images). Also, each image is within a <dl> element, that doesn't give any useful information to users:

https://cldup.com/m07kUdxgho.jpg

https://cldup.com/PYrQBKhoAB.jpg

https://cldup.com/wKboHchwkB.jpg

I'd like to propose to use the same pattern used for the Image preview, and provide some extra info for each image in the gallery. Also, as a user I'd like to know how many images are displayed in the preview: using an unordered list with each image in a <li> element would make assistive technologies announce that automatically.

Attachments (1)

43137.diff (4.7 KB) - added by afercia 5 months ago.

Download all attachments as: .zip

Change History (6)

@afercia
5 months ago

#1 @afercia
5 months ago

  • Keywords has-patch added

43137.diff is a first pass:

  • refactors the previews templates
  • when the images have no alternative text, uses an aria-label attribute Current image has no alternative text. The file name is: %s
  • makes the gallery preview an unordered list
  • when the gallery has more than 6 images, hides the last image to assistive technologies with aria-hidden="true" and expands the "more images" text with an aria-label attribute. Instead of, for example "+3" assistive technologies will announce "Additional images added to this gallery: 3"
  • removes an unused describedById variable in the gallery template

#2 @afercia
5 months ago

Screenshots to illustrate what the patch does. Screen readers are now able to announce the number of items in a gallery preview, the alternative text when present, a meaningful text when the alternative text is not present, and a more useful text instead of just "+2":

https://cldup.com/NNumaK2FhG.jpg

to evaluate:

  • maybe add some visually hidden text before the previews, e.g. "Image preview" and "Gallery preview"
  • is the file name the most useful info to provide? Or maybe the attachment title with fallback to the file name?

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


5 months ago

#4 @afercia
5 months ago

  • Milestone changed from Awaiting Review to 5.0

#5 @Cheffheid
5 months ago

I'd probably go with the attachment title first, and filename second. That way, there's at least the option to override the filename should there be a need to do so (because filenames are pretty dreadful more often than not, sadly).

Note: See TracTickets for help on using tickets.