Opened 3 weeks ago
Closed 11 days ago
#62107 closed defect (bug) (invalid)
The WordPress media library does not use its own alt text
Reported by: | CynicalStudios | Owned by: | joedolson |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | trunk |
Component: | Media | Keywords: | has-patch |
Focuses: | accessibility | Cc: |
Description
The WordPress media library does not use its own alt text when displaying images.
Steps to reproduce:
- Visit the media library (i.e. /wp-admin/upload.php)
- Upload and set alt text on several images
- None of the images displayed use their own alt text, rather they all have alt=""
This is fixable by editing /wp-includes/media-template.php from as follows to use alt="{{ data.alt }}":
(this section is findable by searching "attachment-preview js--select-attachment")
<div class="thumbnail"> <# if ( data.uploading ) { #> <div class="media-progress-bar"><div style="width: {{ data.percent }}%"></div></div> <# } else if ( 'image' === data.type && data.size && data.size.url ) { #> <div class="centered"> <img src="{{ data.size.url }}" draggable="false" alt="{{ data.alt }}" /> </div> <# } else { #> <div class="centered"> <# if ( data.image && data.image.src && data.image.src !== data.icon ) { #> <img src="{{ data.image.src }}" class="thumbnail" draggable="false" alt="{{ data.alt }}" /> <# } else if ( data.sizes && data.sizes.medium ) { #> <img src="{{ data.sizes.medium.url }}" class="thumbnail" draggable="false" alt="{{ data.alt }}" /> <# } else { #> <img src="{{ data.icon }}" class="icon" draggable="false" alt="{{ data.alt }}" /> <# } #> </div> <div class="filename"> <div>{{ data.filename }}</div> </div> <# } #> </div>
Change History (8)
This ticket was mentioned in PR #7430 on WordPress/wordpress-develop by MatthewSbar.
3 weeks ago
#1
- Keywords has-patch added
#2
@
3 weeks ago
- Component changed from Upload to Media
- Owner set to joedolson
- Status changed from new to accepted
#3
@
3 weeks ago
From what you're saying, this is specific to when the images are newly uploaded; can you clarify?
#4
@
3 weeks ago
It doesn't matter if it was just uploaded or not - the thumbnails in the media library all have "intentionally blank alt text" in the code - notice the alt="" in five places in the snippet below from in /wp-includes/media-template.php.
As far as I can tell, there's no other mechanism to determine what the thumbnail is showing to a visually impaired user, and the thumbnails are not decorative in nature, so their alt text should be included in the markup. Let me know if I'm off base on anything here.
I tested this locally with a mix of images that do and do not have alt text added and my change gets the job done without causing any errors for the media library grid in particular. There are other places where a similar adjustment is warranted but I wanted to keep the scope of this change small for now.
Once again this is the code as it is today, which uses alt="" rather than alt="{{ data.alt }}"
<div class="thumbnail"> <# if ( data.uploading ) { #> <div class="media-progress-bar"><div style="width: {{ data.percent }}%"></div></div> <# } else if ( 'image' === data.type && data.size && data.size.url ) { #> <div class="centered"> <img src="{{ data.size.url }}" draggable="false" alt=""/> </div> <# } else { #> <div class="centered"> <# if ( data.image && data.image.src && data.image.src !== data.icon ) { #> <img src="{{ data.image.src }}" class="thumbnail" draggable="false" alt="" /> <# } else if ( data.sizes && data.sizes.medium ) { #> <img src="{{ data.sizes.medium.url }}" class="thumbnail" draggable="false" alt="" /> <# } else { #> <img src="{{ data.icon }}" class="icon" draggable="false" alt="" /> <# } #> </div> <div class="filename"> <div>{{ data.filename }}</div> </div> <# } #> </div>
#5
@
2 weeks ago
- Milestone Awaiting Review deleted
- Resolution set to invalid
- Status changed from accepted to closed
I've looked into this, and while this is technically true, it is not an accessibility issue. In all cases where the images are displayed in the media library, they are wrapped in controls - either a link or a role="checkbox"
with an aria-label
attribute that provides the accessible name.
This was a decision made in how to design this interface for a few reasons. One, using the alt directly can lead to an empty accessible name if the image has a blank alt text. This may be legitimate in the image's use context, but is never appropriate in the admin. Second, we don't define an alt text for non-image media, but we do list them in the library. In this case, they need to use the name field anyway.
Using the alt text in these contexts would 1) be overridden by the wrapping aria-label
and 2) could lead to a confusing interface due to the wide ranging content an alt text can contain.
In the upload media interface, the added image is shown with an empty alt text, but is not linked. At that time, we don't yet have any alternative text, but the name of the file is shown as a link. Since that's the only information known at this stage, this is appropriate.
Given this context, I'm going to close this ticket as invalid; but feel free to continue the conversation. Thank you!
#6
@
12 days ago
- Resolution invalid deleted
- Status changed from closed to reopened
I hope it's okay I reopened this - my issue with the "checkbox with an accessible name" approach is that it actually shows the filename even for images with alt text.
As a real-life example from my day job - MacOS voiceover will read the tile associated with this image as "DCT-2103-logo garden-01@2x" rather than "PBS logo". It's pretty clear which is going to help a visually impaired person find the image.
Obviously, it's not the best filename in the world, but, WCAG is only focused on the image name being accessible, not the filename. You can see from the fact that the filename accessibility rule has been deprecated(1) and replaced with the rule that image names should be accessible(2). It's considered an accessibility failure if the filename isn't suitable as alt text(3). There are a handful of reasons not to warp filenames around accessibility (you can only have a filename in one language but alt text in many languages, as an example).
I totally understand not using the alt text if there is none available, but I don't think in a world where WordPress allows us to add alt text to images, that the alt text should not be used as a label for said images - probably some kind of hybrid approach would be best for cases where there maybe be multiple images with the same description but different filenames due to differences in crop/resolution etc. Continuing this example, the checkbox's label perhaps should be "PBS Logo - filename is DCT-2103-logo garden-01-@2x"
That being said, my initial patch was naive in the sense that it doesn't adjust the checkbox label you mentioned, as I hadn't noticed it due to it not using the actual alt text. I can put in an updated patch if such a thing is warranted but if I won't bother if it's still seen as invalid. Let me know.
1: https://www.w3.org/WAI/standards-guidelines/act/rules/9eb3f6/proposed/
2: https://www.w3.org/WAI/standards-guidelines/act/rules/qt1vmo/
3: https://www.w3.org/WAI/WCAG21/Techniques/failures/F30
#7
@
12 days ago
To be clear, it does *not* use the file name; it uses the attachment title. In the screenshot you shared, the title is using the file name, so you're seeing the file name - but that's only because the title has not been changed.
The title is intended as display information for administration, and is the name of the attachment used for display in the admin. The file name is only used if at the time of file upload there is no other naming information available. The title can also be pulled from exif or iptc data, if it's provided in the image meta.
The title field should always be present, unlike the alt
attribute, and is a field intended specifically for administrative use, which can be more flexible than the alt attribute, which is always tied to a front-end use.
Trac ticket:
https://core.trac.wordpress.org/ticket/62107