WordPress image's title is not alt

[odie2]

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

[odie2]

Replying to swissspidy:

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

[joedolson]

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.

[odie2]

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.

[afercia]

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.

[joedolson]

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.

[SergeyBiryukov]

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.

[afercia]

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

[afineman]

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.

[joemcgill]

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.

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

[odie2]

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

[joemcgill]

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.

[joedolson]

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

[joemcgill]

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

[joemcgill]

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.