WordPress.org

Make WordPress Core

Opened 20 months ago

Closed 8 months ago

Last modified 8 months ago

#34635 closed defect (bug) (fixed)

WordPress image's title is not alt

Reported by: odie2 Owned by: joemcgill
Milestone: 4.7 Priority: normal
Severity: normal Version: 4.3
Component: Media Keywords: has-patch has-unit-tests commit
Focuses: ui, accessibility, javascript Cc:

Description

Hi,

With latest update of Tiled Galleries in Jetpack I found an significant issue on accessibility with images in WordPress.

First, why WordPress use image's title as alt? It's not the same, but Insert Media (attachment 1) and Edit Media (attachment 2) in modal view in visual editor just don't care.

Title is http://www.w3schools.com/tags/tag_title.asp,
Alt is http://www.w3schools.com/tags/att_img_alt.asp.

---

Second, most of images are P1040480.jpg and DSC06635.jpg, so what sense makes to set alt="DSC06635.jpg" to make noise for screen readers?
In most of galleries (like my - even up to 200 random photos of past event) if Editor didn't described photos, it's better to leave empty alt tag (as could be deduced from as we can read on http://accessibility.psu.edu/images/imageshtml/) as system can't provide any alternative info if human didn't provided it.

---

Attachment 3 and 4.

Omitting that's Tiled Gallery, let's analyze it like normal gallery or some single images inserted. As we can see, image source (src tag) couldn't be loaded, so attachment 3 with empty alt tag displays empty image space, in attachment 4 there is alt attribute set, however it's automatical title of image taken by camera.

For screen readers and search engines the attachment 3 is much better. Of course you can say that attachment 4 is better for non-disabled humans, BUT realize that destination of photos on attachments is just gallery (in this case 77 random photos, not described, because Editor ignorance [I am only Administrator, not Editor]). In this case the screen readers and search engines experience is much more valuable as it's better for them to have nothing instead of noise.

---

If you follow my thinking you can say: "OK, but what with Editors habits?".
I have following suggestion - force setting alt rather than title with uploading Media. The title field is just designed for title attribute, but attachment 1 and 2 shows that someone missed that concept. Alternative we can make option in Media settings to choose behaviour. Or maybe you, Dear reader have any better ideas?

In fact most of photos are from camera and without changed names, so this is important.
In times when more and more goverments parts and institutions (at least in Poland) decide to use WordPress for their websites and they have to match WCAG 2.0 requirements on certain A(AA) level, and also it have big impact on normal sites, we should solve this issue as fast as we can.

Greetings

Attachments (6)

1.png (105.8 KB) - added by odie2 20 months ago.
2.png (359.1 KB) - added by odie2 20 months ago.
3.jpeg (15.3 KB) - added by odie2 20 months ago.
4.jpeg (18.4 KB) - added by odie2 20 months ago.
34635.diff (4.3 KB) - added by joemcgill 8 months ago.
34635.2.diff (4.4 KB) - added by joemcgill 8 months ago.

Download all attachments as: .zip

Change History (38)

@odie2
20 months ago

@odie2
20 months ago

@odie2
20 months ago

@odie2
20 months ago

#1 @odie2
20 months ago

  • Keywords 2nd-opinion added
  • Severity changed from normal to major

#2 follow-up: @swissspidy
20 months ago

  • Component changed from Media to Gallery
  • Severity changed from major to normal

#3 in reply to: ↑ 2 @odie2
20 months ago

  • Component changed from Gallery to Media

Replying to swissspidy:

It's not only for galleries. It's also for single images inserted in visual editor.

#4 follow-up: @joedolson
20 months ago

The problem with forcing people to provide an alt attribute is that an alt attribute is *not* always required; in some cases, the alt attribute should explicitly be left blank.

If you have any good ideas about how to handle making alt attributes required while simultaneously allowing them to be blank, we're all ears.

In my plug-in WP Accessibility, I've enabled requirements for alt attributes that allow the user to check a box indicating that the image should not have an alt attribute, but that's the best I've been able to do, so far.

#5 in reply to: ↑ 4 @odie2
20 months ago

Replying to joedolson:

In my plug-in WP Accessibility, I've enabled requirements for alt attributes that allow the user to check a box indicating that the image should not have an alt attribute, but that's the best I've been able to do, so far.

I just thought the same before I readed the last paragraph. It seems like the best possible idea for me.

#6 follow-up: @afercia
20 months ago

  • Focuses javascript added
  • Keywords needs-patch added; 2nd-opinion removed
  • Version changed from 4.3.1 to 4.3

As far as I see, the real problem is when inserting images into a post. To reproduce:

  • have one image in the media library with no alt attribute and title, say, "456789.jpg"
  • edit a post and press the Add Media button
  • in the media modal, select the "456789.jpg" image
  • in the right sidebar, under "Attachment Details" the image has a title and an empty alt attribute
  • press the button "Insert into post"
  • the image will be inserted and the alt attribute will be set to "456789.jpg". Worth noting that's not what the UI just showed me since the alt attribute in the attachment details was empty and I wanted to leave it empty intentionally

Looks like in media-editor.js the alt attribute is forced to be always populated with some value, if there's a suitable value to use:

// Generate alt fallbacks and strip tags.
if ( 'image' === props.type && ! props.alt ) {
	props.alt = props.caption || props.title || '';
	props.alt = props.alt.replace( /<\/?[^>]+>/g, '' );
	props.alt = props.alt.replace( /[\r\n]+/g, ' ' );
}

So if there's no alt attribute, it will try the caption first and then the title. If both are empty, the alt attribute will be empty. This could work when the title (or the caption) have a meaningful text but when not, having images with an alt attribute like "456789.jpg" should be definitely avoided.
Maybe this fallback would need some re-thinking, there's also the chance to have the caption and alt attribute set to the same value, which is a bit redundant.

#7 @joedolson
20 months ago

It's a tricky UI challenge to ensure both options, but I definitely agree that the current behavior can potentially be very wrong.

Does anybody know where the Image Flow project stands? Is that project still active? If so, this may be best punted until a completely re-designed media process; but if they aren't, we should definitely tackle this.

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


20 months ago

#9 in reply to: ↑ 6 @SergeyBiryukov
18 months ago

Replying to afercia:

So if there's no alt attribute, it will try the caption first and then the title.

Related: #18984 (specifically ticket:18984:32), #26270.

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


16 months ago

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


12 months ago

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


12 months ago

#13 @afercia
12 months ago

  • Milestone changed from Awaiting Review to 4.6
  • Owner set to joemcgill
  • Status changed from new to assigned

Related: #36735. Also, the field should always show what's going to be used as alt text. A good first step would be what's proposed on #36735. Assigning to @joemcgill as he's the owner of the other ticket and he's the best person to make a decision and see if the two tickets can be handled together. Or punted together :)

Last edited 12 months ago by afercia (previous) (diff)

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


12 months ago

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


12 months ago

This ticket was mentioned in Slack in #core-images by joemcgill. View the logs.


11 months ago

#17 @afineman
11 months ago

Related: #36868
Since Site Identity uses Media Library and this ticket relates to alt tags with Media Library Images. The solution to both could likely be the same or at least related.

#18 @joemcgill
11 months ago

  • Keywords early added
  • Milestone changed from 4.6 to Future Release

I think the ultimate fix here will be to change the current expected behavior of the alt fallbacks when inserting images from the media library into post content and possibly pre-filling alt attributes when an image is uploaded to the media library. However, I think we'll need more time to get feedback and do some user testing before landing on a solution, so we should take another look at this early in the next release cycle.

A few additional things to consider:

  1. My understanding is that setting the alt attribute to and empty string, like alt="" should really only happen when the image is not a key part of the content (i.e., decorative images). I worry a bit that we're going to end up with a lot of content creators adding empty alt attributes to images that really should be "seen" by assistive technology.
  1. We should also consider how alt fallbacks work for images that are generated on the front end rather than being a part of the post content. For example, featured images generated by the_post_thumbnail(). Having consistent behaviors will help with user expectation.

#19 @odie2
11 months ago

@joemcgill
Problem is when someone upload images for example downloaded from Facebook (often in WP websites I see), the file name is like 13692958_640441422776307_2762172099609496084_o, so this is extra noise for screenreaders and search engines.

I think that then better solution is giving empty alt tag to "hide" it. However the best solution at the moment for me is forcing entering alt text with option to skip entering for certain or disable image alternatives (empty alt tag) at all.

Last edited 11 months ago by odie2 (previous) (diff)

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


10 months ago

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


9 months ago

#22 @rianrietveld
9 months ago

  • Milestone changed from Future Release to 4.7

This ticket was mentioned in Slack in #core-images by joemcgill. View the logs.


9 months ago

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


8 months ago

@joemcgill
8 months ago

#25 @joemcgill
8 months ago

  • Keywords has-patch has-unit-tests added; needs-patch early removed

After much discussion with the A11y team—particularly this Slack conversation—it appears we would be better off not trying to generate fallbacks for the alt attribute whenever an alt value has not been explicitly set. Currently, if no alt value is set, WordPress tries using the caption text before finally falling back to the title. While the intent of these fallbacks is good, in practice they often result in undesirable behavior for people using screen readers.

34635.diff removes the fallbacks so that an alt value will always reflect the value of _wp_attachment_image_alt post meta for that attachment (unless overridden by some other method). I've also added or updated unit tests to reflect this change, but am not certain if some QUnit tests for the editor might be needed. Would appreciate feedback from @iseulde or @azaozz there.

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


8 months ago

#27 @joedolson
8 months ago

Patch looks good to me. Can't judge on the tests. :) Thanks!

@joemcgill
8 months ago

#28 @joemcgill
8 months ago

  • Keywords commit added

34635.2.diff is identical to 34635.diff but removes the now unused fallbacks variable from wp.media.string.props().

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


8 months ago

This ticket was mentioned in Slack in #core-editor by joemcgill. View the logs.


8 months ago

#31 @joemcgill
8 months ago

  • Resolution set to fixed
  • Status changed from assigned to closed

In 38812:

Media: Remove alt fallbacks to improve accessibility.

This removes the fallbacks in wp_get_attachment_image() and in
wp.media.string.props which attempt to generate an alt value
from the image caption or title if an alt attribute isn't explicitly
set.

This allows for image HTML to be generated that contains an empty alt
value, i.e., alt="" which is much preferable for screen readers than
reading redundant content in the case of a caption, or when reading the
image title, which is often generated from the filename and not helpful
as alt text.

Props odie2, joedolson, rianrietveld, afercia, iamjolly, joemcgill.
Fixes #34635.

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


8 months ago

Note: See TracTickets for help on using tickets.