WordPress.org

Make WordPress Core

Opened 8 months ago

Last modified 43 hours 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: high
Severity: normal Version:
Component: Media Keywords: wpcampus-report needs-design-feedback needs-patch
Focuses: accessibility Cc:
PR Number:

Description

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

Problem

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 (14)

#1 @afercia
8 months ago

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

#2 @joedolson
8 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.


8 months ago

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


7 months ago

#5 @karmatosed
7 months ago

  • Keywords needs-design-feedback added

#6 @afercia
7 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.


5 months ago

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


3 months ago

#9 @afercia
3 months ago

  • Milestone changed from Future Release to 5.4

#10 @azaozz
7 days ago

Looking at the ticket description there seem to be some contradictions.

The recommendations are pretty clear:

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.
...
The alt text is not constant: it needs to describe the image purpose on a case by case basis.

But then "1. allow saving multiple alt attributes for a given media object: a default attribute and a set of alternates users can select from ".

Why would there be multiple incorrect/out of context alt texts for the users to select from? This encourages improper use. It is clearly recommended to have different alt text every time the image is used (which in reality is pretty rare for non-decorative images).

It seems that currently this is done "the wrong way" in WP. In order to follow the above recommendations WP should stop storing the alt text in the DB, and encourage the users/authors to enter appropriate alt text every time an image is used, including in galleries, etc.

This will also resolve:

  1. have something in the editor UI that would let users know whether the alt text was filled, and what it says
  2. 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

which, again, seem to encourage improper use of text for the alt attributes.

Also agree with @joedolson's comment about linking directly to the image file. That's often done in order to allow the website visitors to download the image to their computer.

This ticket was mentioned in Slack in #core-media by antpb. View the logs.


6 days ago

#12 @azaozz
4 days ago

  • Keywords needs-patch added
  • Priority changed from normal to high

Thinking a bit more about this (following the #core-media chat).

Until now the assumption was that the alt attribute text should be saved to the DB and reused. There is a lot of code that makes this possible.

Looking at the recommendations on this ticket, they make a lot of sense. In order to comply with them we'll need to:

  • Stop saving alt text in the DB and remove the UI for it.
  • Encourage (require?) adding of alt text each time an image is used/inserted in the editor (i.e. ensure alt text is always contextual).

This will also improve the user experience. Currently adding or changing the alt text is inconsistent. Sometimes it is saved to the DB and reused (when done in the media modal before inserting an image in the editor), in other cases it is on per-post basis (when done directly in the editor after inserting an image). Standardizing on the second method, which is the proper way according to the recommendations, will make it consistent and a lot cleaner/easier to understand.

These are big changes. Not sure they can be implemented in time for 5.4 beta which is in couple of weeks.

Setting this as high priority as it needs a decision whether it can be completed in time, who would be contributing, and who will be reviewing the changes.

Last edited 3 days ago by azaozz (previous) (diff)

#13 follow-up: @joedolson
2 days ago

Just thinking about some of what would need to be done for this, it's a pretty substantial challenge:

  • Need to be able to account for multiple uses in a single instance. E.g., a featured image used on the single post screen serves a different purpose than a featured image linked from an archive page. There would need to be a way that themes could define how a featured image is used by the theme. Or would we pre-define a set of use cases (that could be extended), and provide different arguments to fetch an image based on use case?
  • Need to have alt texts stored for programmatic access: for a featured image, that could be several post meta entries.

Handling alt attributes in posts is relatively trivial; the inserter places the image in a direct context that can be decided on at the time. Programmatically associated images would be much, much harder to handle - both the software and the user would have to have a full understanding of where an image would show up and how it would be used in each case.

There are a lot of mechanisms that would need to be created to make that work - the editor interface is relatively trivial, but usages of media outside of post content raise a lot of questions.

#14 in reply to: ↑ 13 @azaozz
43 hours ago

Replying to joedolson:

Just thinking about some of what would need to be done for this, it's a pretty substantial challenge

Yes, it will require a lot of changes to how things currently work. Also to user "workflows" and UI.

Need to be able to account for multiple uses in a single instance. E.g., a featured image used on the single post screen serves a different purpose than a featured image linked from an archive page.

Right. As "featured images" are a specific use case, the image alt text should be handled specifically for them. That would mean adding (some) UI for entering alternate strings, and having a simple, bulletproof way for themes to get the correct string for each context. Then will need to look at what is the best way to store these alternate text strings, where and how (but these are implementation details, they are relatively "easy" once the workflow(s) and the UI are decided).

Handling alt attributes in posts is relatively trivial; the inserter places the image in a direct context that can be decided on at the time. Programmatically associated images would be much, much harder to handle

Yes, providing context for "programmatically associated" images will (most likely) need to be done on a case by case basis. As featured images are the most common case, getting the alt attribute text to work well there will most likely be reused elsewhere.

There are a lot of mechanisms that would need to be created to make that work - the editor interface is relatively trivial, but usages of media outside of post content raise a lot of questions.

Yeah, thinking this should probably be done in stages as it would need a lot of changes in many different places.

Perhaps the first stage should be to ensure there is suitable/good UI for adding (contextual) alt text in all blocks that add images. Then hide the field in the media modal and stop auto-adding alt text when inserting images in the editor.

Then update the featured image UI and the way it works, and suggest (require?) the user enters appropriate alt text for at least the "known" contexts. It may be possible to make (some of) this into an API for more general use for adding contextual alt text(s) for programmatically associated images.

Thinking that the sooner this starts - the better, but it most likely will take more than a single release cycle to accomplish. At the same time there are other tickets about handling image alt text, like #30180, that would depend on progress on this ticket.

Last edited 43 hours ago by azaozz (previous) (diff)
Note: See TracTickets for help on using tickets.