Make WordPress Core

Opened 5 years ago

Last modified 5 days ago

#47456 accepted defect (bug)

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

Reported by: afercia's profile afercia Owned by: joedolson's profile joedolson
Milestone: Future Release Priority: high
Severity: normal Version:
Component: Media Keywords: wpcampus-report needs-patch phase-3-media-triage
Focuses: accessibility Cc:

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

#1 @afercia
5 years ago

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

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


5 years ago

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


5 years ago

#5 @karmatosed
5 years ago

  • Keywords needs-design-feedback added

#6 @afercia
5 years 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 years ago

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


4 years ago

#9 @afercia
4 years ago

  • Milestone changed from Future Release to 5.4

#10 @azaozz
4 years 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.


4 years ago

#12 @azaozz
4 years 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 4 years ago by azaozz (previous) (diff)

#13 follow-up: @joedolson
4 years 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
4 years 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 4 years ago by azaozz (previous) (diff)

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


4 years ago

#16 @audrasjb
4 years ago

  • Keywords early added
  • Milestone changed from 5.4 to 5.5

Moving to 5.5 with early keyword as this ticket still needs a patch.

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


4 years ago

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


4 years ago

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


4 years ago

#20 @afercia
4 years ago

  • Keywords early removed

This ticket was discussed during today's accessibility bug-scrub: agreed to split it into smaller tickets. Some of the simpler parts could be doable for 5.5. For example:

  • fixing alt text when inserting images in the editor
  • deciding how alt text should work in featured images and implementing it

For more details, see the Slack conversations linked above.

#21 @joedolson
4 years ago

  • Owner set to joedolson
  • Status changed from new to accepted

This ticket was mentioned in Slack in #core by marybaum. View the logs.


4 years ago

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


4 years ago

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


4 years ago

#25 @afercia
4 years ago

#49875 was marked as a duplicate.

#26 follow-up: @apedog
4 years ago

@azaozz

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 is assuming a bit much about how people use WordPress. Also it puts quite an onus on authors to make up an alt text every time an image is re-used. Not all authors/content-creators understand or care about the a11y requirements of the 'alt' attribute.

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).

I'm not sure that's clear at all. In fact I think quite the opposite is true.

A dropdown/select option of previously used 'alt' texts might be very convenient for authors re-using an image in a post or gallery or new contexts. They will naturally (hopefully) select the description most relevant to their specific usage (or add their own for new contexts). Imo not saving previously used 'alt' texts to the DB will actually encourage improper usage. With some authors (especially those that know nothing of a11y requirements) will be annoyed by a prompt to add a description and just filling in 'img123' 'asdfasdf' etc.
Requiring "on-the-fly" descriptions to be added, is way more likely to lead to improper/inconsistent usage.

An image's different alt texts should be associated with the image in the DB, and available through the different interfaces of that image.

This would also allow editors/administrators to more easily review and fix incorrect/inconsistent usage by authors across a website/blog.

#27 in reply to: ↑ 26 @azaozz
4 years ago

Replying to apedog:

This is assuming a bit much about how people use WordPress.

Hmm, this assumes people use WP to create web pages, and upload images to include on these web pages, posts, product descriptions, etc. Commonly images from the media library are either stand-alone (surrounded by text) or grouped in galleries, sliders, etc.

Another, less common case is when images uploaded by the authors are used as backgrounds, icons, etc. In many of these cases the image is added from CSS (no alt attribute) or the alt should be empty as the images are purely decorative.

There are certainly edge cases for use of uploaded images. These are typically added by plugins. In these cases the plugin should be able to support adding of appropriate alt text.

Also it puts quite an onus on authors to make up an alt text every time an image is re-used.

Right. However this is the proper way to do things. See the ticket description and the W3C tutorial: https://www.w3.org/WAI/tutorials/images/decision-tree/.

Not all authors/content-creators understand or care about the a11y requirements of the 'alt' attribute.

Yeah, as @joedolson mentioned in Slack, this is also "an educational challenge". WP will have to find a good way to educate the authors that having good, appropriate alt text enhances their content, and having none, misleading, out-of-context alt text can "harm" their content.

Speaking of reused images, I went through the last ~100 images I used in posts and only 3 were reused. Just curious, could you count how many images (from the media library) you have reused in your recent posts? :)

Last edited 4 years ago by azaozz (previous) (diff)

#28 @apedog
4 years ago

Just curious, could you count how many images (from the media library) you have reused in your recent posts? :)

I was thinking of a friend of mine who is an editor for an online magazine that happens to use WordPress. I see her working. Adding images and captioning is a common occurrence, as is image re-use (paid rights-management etc.) I know how she is when on a deadline. I know there is no way to "educate" all the authors working on that publication about accessibility and HTML standards. They've other things on their mind - and a11y is considered by them to be an upstream issue. A technical issue that is some other professional's responsibility.

Having an image's previously used captions/alt texts available when inserting seems like it would be much more conductive to overall correct usage than requiring "on-the-fly" alt-text generation from the different authors. It would probably also make the technician/administrator's (whoever takes care of a11y on their site) job easier. I'm not privy to their exact workflow.

The idea of "educating" this person I know about HTML standards is just ridiculous. Not something that will happen in a million years. Multiply that by the different content-creators, each with their own idiosyncrasies, employed there over the years - and it becomes obvious that a11y will always be relegated to some other professional who is not a content-creator.

#29 @knutsp
4 years ago

Since the purpose for including an image in a post probably will be the same when re-used, it should be stored with the attachment, as one or many (history). But user should ideally be prompted to select one, write a new or leave empty, with some simple explanation.

When used as a featured image, may be we can figure out something smart?

When used in other contexts, the theme/plugin should have option to suggest alt text for the specific usage.

#30 @afercia
4 years ago

Having an image's previously used captions/alt texts available when inserting seems like it would be much more conductive to overall correct usage than requiring "on-the-fly" alt-text generation

This is a common misconception. The alt text is not meant to describe the image. Instead, it's meant to describe the purpose of the image, which varies depending on the context. Simple, basic, example:

  • Image of a Boeing 747 taking off.
  • Case 1: the image is purely decorative and doesn't add any relevant information to the page content: needs an empty alt text alt=""
  • Case 2: the image is used in a technical article about airplanes to illustrate some detail of the taking off process. Thus, the image adds relevant information. The alt text needs to describe the relevant information regarding the taking off detail.
  • Case 3: the image is used as the only content of a link to the local airport: in this case the image needs to describe the link destination. This would be totally wrong:

<a href="link-to-local-airport-website.html"><img src="boeing747.jpg" alt="A Boeing 747 taking off" /></a>

this would be correct:

<a href="link-to-local-airport-website.html"><img src="boeing747.jpg" alt="Go to the xyz airport website" /></a>

I hope this clarifies why it's wrong to think there can be one alt text that fits all the possible usage cases.

Not all authors/content-creators understand or care about the a11y requirements of the 'alt' attribute.

Apart from the fact I'd call that unprofessional, if authors/content-creators don't really care about crafting correct alt text, the best option in 90% of the cases would be allowing purely decorative images to have an empty alt text by default instead of one filled with not-relevant information. Which is one of the goals of this ticket.

#31 @sabernhardt
4 years ago

Whether or not the alt text continues to be saved to the library, the interface needs to be clearer when these values will not be saved for re-use. People are already confused about how it works now (see tickets #49165, #47808, GB8941, and at least one support ticket).

An image already can have multiple alt texts assigned to it, at least when attaching it to a post. WordPress saves the alt text while you are still in the Media Library or in a library modal ("Insert Media" or "Select or Upload Media"). However, once the image is attached to a post, any edits in the block sidebar (or the "Image Details" modal with Classic Editor) are not saved to the attachment in the database.

Here are a few ideas for improving the interface with respect to that:

  1. Revise the Alt Text input label—whenever it will not be saved—to indicate that it is specific to that particular instance. Perhaps it could say something like "Alt text: describe the purpose of the image in this [block/post-type]" (including a variable).
  2. Split the functions of the media modal into two steps. First, upload or select the image and click a "Continue" button. Then set the Alt Text and related details. The input fields still could be left blank whenever appropriate, yet this would make them more prominent within the workflow.
  3. Consider adding a checkbox so a user can indicate if the alt text for that image should be saved to the library for re-use. Reusable alt text may be unusual, but I suspect it's roughly as common as reusing a block. (I recently inserted an image that serves exactly the same purpose on multiple pages, though I was able to put that inside a reusable block.)

On another note, if the alt text and/or captions are no longer saved with the media attachments, I would miss the ability to set those details for a group of images all at once. Especially when the images' alt text is similar, it's nice to edit that in the media library instead of post-by-post or block-by-block.

#32 follow-up: @joedolson
4 years ago

In order to retain a DRY approach to content authoring, I think that saving alt texts is preferable, and that any alt text written for an image should be retained. The process for using an image should provide the ability to either select an existing alt text based on use or provide a new one.

While it's true that *most* images will be used only once, with only one alt text, I think that use case is not in any way harmed by storing alt texts, where the less-common case where an image is used more than once in the same or similar way would be harmed by the loss of saved alt text.

What's important is to provide a UI that makes it as easy as possible for a content creator to understand the context an image exists in and how alt text applies to that situation. Admittedly, not the most trivial aim; but I don't think that forcing a user to create new alt text every time particularly benefits it.

#33 in reply to: ↑ 32 @jamesvg
4 years ago

Replying to joedolson:

While it's true that *most* images will be used only once, with only one alt text, I think that use case is not in any way harmed by storing alt texts, where the less-common case where an image is used more than once in the same or similar way would be harmed by the loss of saved alt text.

The earlier "airport" example case may test the store-everything model as not causing harm. Using an image in numerous unique contexts (e.g. specifically referencing each airport on a continent) would generate a large list of alts that may never be useful again.

Might it be sufficient and helpful to store an attachment's recently-applied alts to be optionally selected as prefill for the alt text's textarea/input at the point when an attachment is applied to a post? Model:

  • Apply the text from _wp_attachment_image_alt
  • Apply the first-most recent
  • ...
  • Apply the fourth-most recent

Or again to reference the airport example:

  • Apply the attachment's default alt text or another recently-used context?
    • A Boeing 747 taking off
    • Go to the YYZ Airport website
    • A Boeing 747 demonstrating a positive angle of attack for the purposes of increasing lift coefficient during takeoff
    • Go to the MSP Airport website
    • Go to the ATL Airport website

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


4 years ago

#35 @afercia
4 years ago

Related: #50066 (make alt text input a textarea).

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


4 years ago

This ticket was mentioned in Slack in #core by jeffpaul. View the logs.


4 years ago

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


4 years ago

#39 @audrasjb
4 years ago

  • Milestone changed from 5.5 to Future Release

This ticket was mentioned in Slack in #core-restapi by azaozz. View the logs.


4 years ago

#41 @joedolson
4 years ago

Related: #37011 (closed, but adding contextual alt attributes would alter how that issue is solved.)

#42 @vigilant_spb
4 years ago

Let's say I have a photo of a house. Upload it. Type in alt: "house sized 10*10 meters with red roof". It is house on photo, right? Right. I insert it in my post.

2 years passed.

I'm writing new post and suddenly call to my mind "hmmm I used to post one photo before, let me search". Open media library, type "house red roof" and see my photo uploaded 2 years ago.

Still same house. Roof is definitely red. Alt text is actual - describing what's here. I insert in my new post. Cool!

---

But what we have now: I write post, drag and drop photo, write alt in Gutenberg sidebar. Alt isn't saved in medialibrary! "It's expected" you say.. Oook.
In 2 years I open ML -> search, nothing is found - cool, yeah?

---

Since 2015 I used to fill only title for every uploaded photo leaving alt empty. I uploaded thousands. This nice titles appeared in my full-screen lightbox/colorbox, users saw those descriptions, it was useful.

Some moment you decided to kick titles. Obsolete. Wow! Now I have same POST titles in all my old galleries, I'm "happy".

Also old versions could use link to mediafile by default. New Gutenberg can't do this. And, more to say, it has NO alt editing for galleries.

My nice workflow now is

  1. insert photo
  2. check link is none, change it to "mediafile" (cause I want to zoom in with ligthbox)
  3. fill alt text, copy it
  4. open media library, paste alt for my image
  5. insert 3 photos together
  6. check gallery link to none, change to mediafile
  7. find out I have no alt field
  8. shout out loud some bad words
  9. delete gallery
  10. open media library
  11. find my photos, fill alt text
  12. insert these photos like gallery
  13. change link to mediafile..

I don't like it. Sure I can use old classic editor. Upload photos first, write alts for them BEFORE inserting to the post, write my post and select photos from library. But is it convenient? Not so.

Please improve workflow for media. Bring alt sync back. Show me the way to use my old titles instead of alts for old galleries. Make an option link to media file by default for every inserted image.

Make wordpress great agian!)

Version 0, edited 4 years ago by vigilant_spb (next)

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


4 years ago

This ticket was mentioned in Slack in #design by multidirectionaldesig. View the logs.


3 years ago

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


3 years ago

This ticket was mentioned in Slack in #design by paaljoachim. View the logs.


3 years ago

#47 @estelaris
3 years ago

  • Keywords needs-design-feedback removed

Removing the needs-design feedback label after reviewing the ticket. This is a structural change and not design related.

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


2 years ago

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


23 months ago

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


16 months ago

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


5 months ago

#52 @joedolson
5 months ago

  • Keywords phase-3-media-triage added

#53 @sabernhardt
5 days ago

#60811 was marked as a duplicate.

Note: See TracTickets for help on using tickets.