#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)
Change History (39)
#2
follow-up:
↓ 3
@
9 years ago
- Component changed from Media to Gallery
- Severity changed from major to normal
#4
follow-up:
↓ 5
@
9 years 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
@
9 years 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:
↓ 9
@
9 years 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
@
9 years 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.
9 years ago
#9
in reply to:
↑ 6
@
9 years 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.
9 years ago
This ticket was mentioned in Slack in #accessibility by afercia. View the logs.
8 years ago
This ticket was mentioned in Slack in #accessibility by rianrietveld. View the logs.
8 years ago
#13
@
8 years 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 ticket can be handled together. Or punted together :)
This ticket was mentioned in Slack in #accessibility by afercia. View the logs.
8 years ago
This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.
8 years ago
This ticket was mentioned in Slack in #core-images by joemcgill. View the logs.
8 years ago
#17
@
8 years 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
@
8 years 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:
- My understanding is that setting the
alt
attribute to and empty string, likealt=""
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 emptyalt
attributes to images that really should be "seen" by assistive technology.
- 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 bythe_post_thumbnail()
. Having consistent behaviors will help with user expectation.
#19
@
8 years 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.
This ticket was mentioned in Slack in #accessibility by joemcgill. View the logs.
8 years ago
This ticket was mentioned in Slack in #accessibility by joemcgill. View the logs.
8 years ago
This ticket was mentioned in Slack in #core-images by joemcgill. View the logs.
8 years ago
This ticket was mentioned in Slack in #core by jeffpaul. View the logs.
8 years ago
#25
@
8 years 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 years ago
#28
@
8 years ago
- Keywords commit added
34635.2.diff is identical to 34635.diff but removes the now unused fallbacks
variable from wp.media.string.props()
.
Replying to swissspidy:
It's not only for galleries. It's also for single images inserted in visual editor.