Make WordPress Core

Opened 7 months ago

Last modified 7 weeks ago

#47456 new defect (bug)

Improve the user interface to ensure correct usage of the image alt text

Reported by: afercia Owned by:
Milestone: 5.4 Priority: normal
Severity: normal Version:
Component: Media Keywords: wpcampus-report needs-design-feedback
Focuses: accessibility Cc:
PR Number:


Splitting this out from the WPCampus accessibility report issues on the Gutenberg GitHub, see https://github.com/WordPress/gutenberg/issues/15309 as part of the reported issue applies to the Media Views in core.

Related: #41467


A common misconception is that the image alt text should always be a "description of the image". In most of the cases, this is misleading. Actually, the image alt text needs to describe the purpose of the image in its specific context. For more details, see the W3C Alt Text Decision Tree tutorial (https://www.w3.org/WAI/tutorials/images/decision-tree/).

WordPress stores a "default" alt text in the media object. While storing a default value may help users when they build their content, it also promotes a misunderstanding of the purpose of the alt text.

In the accessibility team, we think this is more an user interface problem rather than a data model problem. The user interface should ensure users clearly understand that alt attributes are context sensitive and that the "default" alt value needs to be changed (or even removed) based on the specific usage.

Data model problem:

The alt text is not constant: it needs to describe the image purpose on a case by case basis.

User interface problem:

The alt text from the media library is automatically assigned as the alt text within the post: this is not always correct. Actually, in most of the cases it produces wrong alt text.

Improvements to evaluate

Credits: Some of the following points come from @carlseibert and @joedolson comments on #41467, and from the Gutenberg GitHub issue.

  1. allow saving multiple alt attributes for a given media object: a default attribute and a set of alternates users can select from
  2. have something in the editor UI that would let users know whether the alt text was filled, and what it says
  3. modifications on the Media views side to differentiate between the alt text describing the image and the alt text for a specific usage, which might override the normal alt text without changing it
  4. all linked images must have alternative text if the image is the sole content of the link, and the action should be blocked if this is not true
  5. any guidance given should inform users that the text provided needs to inform the user of the link action
  6. include a warning about linking directly to the image file: linking directly to images is inadvisable, because the resulting image view in the browser does not include alternate text
  7. when the image is linked to the image file itself, the alt text can remain the normal alternative text for that image, with an appended indicator that the link is to view the image
  8. worth considering plugins that add "lightbox" modals, sliders and the like often use the alt text value to add contextual text within their UI
  9. images used to link to other resources should offer a field to add dedicated link text separate from the image's own description; in this case the alt text should be empty. Example markup (simplified):

Change History (9)

#1 @afercia
7 months ago

@joedolson when you have a chance, please do feel free to check if I missed anything important.

#2 @joedolson
7 months ago

6) I'd argue that there's nothing wrong with linking directly to an image file, as long as the alt attribute or link text clearly indicates that this is a link to an image file. Though a direct link to an image file is of no use to a screen reader user, a link to (for example) a full sized version of an image can be of significant use to low vision users, and can be desirable for some images. It's certainly not a primary usage that has any benefits, but I think that as long as screen reader users are able to identify that this link is not of value to them, there's no great reason to discourage it.

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

6 months ago

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

5 months ago

#5 @karmatosed
5 months ago

  • Keywords needs-design-feedback added

#6 @afercia
5 months ago

  • Milestone changed from Awaiting Review to Future Release

Discussed during today's accessibility bug scrub and agree to move to Future Release. The scope of this ticket is broad and would require some research and planning.

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

3 months ago

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

7 weeks ago

#9 @afercia
7 weeks ago

  • Milestone changed from Future Release to 5.4
Note: See TracTickets for help on using tickets.