The function theme_file_icon($variables) returns code which includes an empty alt attribute. I believe it would correctly return an alt attribute such as "PDF" for a PDF file, etc.
If it is determined that this icon is purely decorative (and if it is, then why is the title attribute filled in?) and is properly a null alt attribute, then add a class "decorative" so that automated checking for missing/null alt attributes can be taught to ignore the lack of an alt attribute, to distinguish it from content where site content providers neglected to provide an alt attribute.
Comments
Comment #1
Charles BelovComment #2
mgiffordNote that this is still a problem with this function.
https://api.drupal.org/api/drupal/core!modules!file!file.module/function...
Comment #3
mgiffordHere's the patch. I'm actually in favour of nixing the title tag here.
More info on the ideal here #1919940: Build API to Replace Links using Title Attributes with Proper Accessible, Themable Tooltips
Comment #4
Charles BelovActually, returning the mime isn't particularly friendly as alternate text. I'm guessing a non-technical person would not find it helpful to hear, say, "application slash pdf". It would probably be more useful to hear "PDF icon" or "PDF".
Hope this helps.
Comment #5
mgiffordThere are about 350 mime types that Drupal manages here https://api.drupal.org/api/drupal/core!includes!file.mimetypes.inc/funct...
Any case for a more human friendly string would involve checking the mime type and then providing a human friendly alternate.
See:
www.freeformatter.com/mime-types-list.html#mime-types-list
http://stackoverflow.com/questions/18038676/getting-mime-type-descriptio...
Comment #6
Charles BelovHowever, there are only 14 icons in \modules\file\icons\. I believe 14 alternate texts would be quite manageable.
text-x-generic.png Text icon
text-x-script.png Script icon
video-x-generic.png Video icon
x-office-document.png Office document icon
x-office-presentation.png Office presentation icon
x-office-spreadsheet.png Office spreadsheet icon
application-octet-stream.png Binary code icon
application-pdf.png PDF icon
application-x-executable.png Program icon
audio-x-generic.png Audio icon
image-x-generic.png Image icon
package-x-generic.png Package icon
text-html.png HTML icon
text-plain.png Plain text icon
Comment #7
mgiffordOk, so if we restrict it to just those it can look a bit more like this.
Comment #8
mgiffordThese are easy:
txt, pdf, doc, html, jpg, gif, png, xls, ppt
'application/msword' => t('Microsoft Office document icon'),
'x-office-presentation' => t('Office presentation icon'),
'x-office-spreadsheet' => t('Office spreadsheet icon'),
'application/pdf' => t('PDF icon'),
'image/jpeg' => t('Image icon'),
'image/png' => t('Image icon'),
'image/gif' => t('Image icon'),
'text/html' => t('HTML icon'),
'text/plain' => t('Plain text icon'),
But there are alternates http://filext.com/faq/office_mime_types.php
Not sure about:
mp4, mov, wav, mp3, bin, exe
Or if there are others, but don't think these are useful:
// 'text-x-generic' => t('Text icon'),
// 'text-x-script' => t('Script icon'),
// 'video-x-generic' => t('Video icon'),
// 'application-octet-stream' => t('Binary code icon'),
// 'application-x-executable' => t('Program icon'),
// 'audio-x-generic' => t('Audio icon'),
// 'package-x-generic' => t('Package icon'),
Again, not sure which variations or for that matter what the default should be:
http://www.php.net/manual/en/function.mime-content-type.php
Where did you get your list?
Comment #10
mgiffordarg
Comment #11
mgiffordThis needs to be extended, but is the results from a WAVE scan of one of the pages showing the alt text for the images.
Comment #14
dawehnerIt seems to be possible to reuse information coming from file_default_mimetype_mapping()
Comment #15
Charles BelovI got my list of MIME-type icons from the docroot/modules/file/icons/ folder. You only need alternate text for images that exist, and there are only those 14 images.
Those other mime types don't have images in that folder, so they don't need to have alternate text added. However, if you do add images for those other MIME types, then alternate text needs to be added as well.
That does bring up the larger issue that someone could add images. In theory, they aren't supposed to modify core. I don't know whether the Files module supports looking in some other location for additional images this, but if they did add images, they would also need to add alternate text, presumably by overriding the theme_file_icon function, same as I have until this issue is fixed and pushed to production.
This points to the question, presumably for Drupal 8, not Drupal 7, whether mime type icons and their corresponding alternate text belong in configuration rather than docroot/modules/file/icons/ (for the icons) and code (for the alternate text).
In terms of scope control for the current issue though, there are only 14 images and therefore only 14 alternate texts are needed.
Comment #16
mgiffordThanks @Charles Belov. It's good to keep it focused if we can.
@dawehner file_default_mimetype_mapping() doesn't get us any closer to a human readable string like "Microsoft Word Document".
Comment #17
mgiffordThere is a duplicate here #1507754: Give file icons alt text
Not sure which should be closed.
Comment #18
mgifford10: theme_file_icon-alt-text-2163209-9.patch queued for re-testing.
Comment #19
mgiffordKeeping this issue open.
Comment #20
mgiffordNo longer applies.
Comment #21
andrewmacpherson CreditAttribution: andrewmacpherson commentedtheme_file_icon()
has been removed as part of the twig effort, replaced bytemplate_preprocess_file_link()
(see #1898070: file.module - Convert theme_ functions to Twig).This patch just re-implements the list of text-alternatives from comment #9. It also fixes the text for spreadsheets and presentation (they were the wrong way round).
However, it doesn't work for some mime-types. If an MS-word ".doc" file is uploaded, the icon gets alt text, but if an OpenDocument ".odt" file is uploaded, there is no alt text.
The approach we're using so far is to determine the alt text based on the mime-type, but some generic icons get used for several mimetypes (notably the office ones, see
file_map_icon()
). If we determine the alt text by mime-type, then we don't have nearly enough human-names. Perhaps we need an equivalentfile_map_alt_text()
? Do mime-types have "official" human-readable names we can use as our source?Alternatively, we could keep the list of text-alternatives short if we map them to the icon image instead of the mime-type.
Comment #22
andrewmacpherson CreditAttribution: andrewmacpherson commentedSorry, I missed the links referenced in comment #5.
The list at http://www.freeformatter.com/mime-types-list.html looks like a good start if we decide to go for a big list of human-friendly names for mime-types, although the author says it not an "official" list.
Comment #23
andrewmacpherson CreditAttribution: andrewmacpherson commentedIf this is committed, we might mention it in the D8 accessibility features blurb at
https://www.drupal.org/drupal-8.0/features#accessibility
Comment #24
mgiffordThanks for patch and link to #1898070: file.module - Convert theme_ functions to Twig and fixes.
I do like the idea of adding more icons, especially for OpenDocument (OpenOffice or LibreOffice), but that should be a different issue. We've only got to contend with the following in this issue:
$ ls core/modules/file/icons/
application-octet-stream.png audio-x-generic.png text-html.png text-x-script.png x-office-presentation.png application-pdf.png image-x-generic.png text-plain.png video-x-generic.png x-office-spreadsheet.png application-x-executable.png package-x-generic.png text-x-generic.png x-office-document.png
I like the idea of extending the icons to include a more full range of extensions and mime types, putting them in a file_map_alt_text() function would be great. But I'd like to see that extended list be a new issue. Right now we just have to worry about providing alt tags for the images we actually use.
I modified the patch to include binary files and also provide a default if the mimetype isn't described.
If we don't have images for the big list, we don't need human readable alt text for it. That's what I figure in any case.
Comment #25
davidhernandezI tested this and achieved the desired result on the node edit form and the node display. Do you want to RTBC this or do any other mime types need adding?
Comment #26
mgiffordI don't think we need to address the other mime types at this time. We can save that for D9. This will hit 90% of use cases I think.
Just need someone to mark as RTBC as far as I'm concerned.
Comment #27
davidhernandezComment #29
mgiffordReroll..
Comment #30
davidhernandezComment #31
webchickOooh, this is really nice. The only thing we might want to do here is pull that into a helper function so that you can easily get that list that from other places, but we could always do that in a follow-up.
Committed and pushed to 8.x. Thanks!
Comment #33
mgiffordIs this something that can be backported to D7?
Comment #34
webchickI don't see why not.
Comment #35
mgiffordOk, I think this is a good first start. Seems to be working here:
Comment #36
dcam CreditAttribution: dcam commented#35 looks good to me. The change is the same as what went into 8.x, with respect to the differences in the theme system between the two versions. I get the same result as is shown in #35's attached image. After applying the patch and clearing the cache the alt attribute is added to file download link icons.
Comment #39
dcam CreditAttribution: dcam commentedComment #42
dcam CreditAttribution: dcam commentedComment #45
dcam CreditAttribution: dcam commentedComment #48
mgiffordbad bot.
Comment #51
dcam CreditAttribution: dcam commentedComment #54
dcam CreditAttribution: dcam commentedComment #57
dcam CreditAttribution: dcam commentedComment #58
David_Rothstein CreditAttribution: David_Rothstein commentedHm, I think there are a few problems here (see attached patch and interdiff):
Comment #59
David_Rothstein CreditAttribution: David_Rothstein commentedI'm also not sure file_get_mimetype($file->filename) is correct... shouldn't it be file_get_mimetype($file->uri)?
I believe $file->filename can sometimes be a human readable name (like "My PDF File") rather than something with an extension, like my-pdf-file.pdf...
Comment #60
mgiffordI don't know, looks better from the API, but it should be easy to test. This patch includes file_get_mimetype($file->uri).
They both seem to work fine. Would be good to know what test case one would fail.
Comment #61
ruha CreditAttribution: ruha at Scout Marketing commentedThis patch addresses an issue I'm having with a site right now. I'm having trouble getting it to work on 7.37 with PDFs. I am getting the alt tags on the node edit page but not on the node view page.
Comment #62
mgifford@ruha - want to mark it RTBC?
Comment #63
jasonflaherty CreditAttribution: jasonflaherty commentedHello, was just looking into this issue. Is the idea to add a patch to drupal core for this or should I begin looking to a preprocess function? Thanks!
Comment #64
mgifford@buildakicker the goal was to add the patch to core. Although perhaps there's a better way to do this.
Comment #65
jasonflaherty CreditAttribution: jasonflaherty commentedThanks @mgifford. This is a good for accessibility, not perfect, but a good fix. I ended up using a preprocess in the time being:
Not sure if this is the best solution... but it does describe the icon :).
Thanks!
Comment #67
mgiffordComment #68
talhaparacha CreditAttribution: talhaparacha commentedThe patch at #60 applied cleanly. Not need for a re-roll. Tested a few file types after applying patch, works as expected.
Comment #69
joewhitsitt#60 Applied cleanly to core 7.39. Tested with PDF file icons and got the expected alt="PDF icon" result.
Comment #70
David_Rothstein CreditAttribution: David_Rothstein as a volunteer commentedCommitted to 7.x - thanks!
We should consider a followup to see if $file->mimetype can simply be used here - not sure why it wouldn't work.
Comment #72
David_Rothstein CreditAttribution: David_Rothstein as a volunteer commentedI misspoke on the name of the file object property above, but I think I had the idea right :) See related issue.
Comment #73
David_Rothstein CreditAttribution: David_Rothstein as a volunteer commentedAlso, I should mention, I should have found and committed this issue earlier in the release cycle (since it adds translatable strings, and we want to give translators time to translate them).
But in the end, I think untranslated alt text for these images is likely better than no alt text at all (maybe?) so I went ahead and committed it now anyway.
Comment #75
Daniel.Moberly CreditAttribution: Daniel.Moberly commentedWhy are we only allowing end users to modify the alt tag for theme_file_icon? Doesn't it make more sense to just allow users to do whatever they want with the tags like in theme_image? I don't see why there is a case to be made that users should be able to add alt text but not their own classes or height/width values (which are flagged as missing by many code-review systems such as Google Developer Tools). Personally I know I have cases where I am manually adding height/width tags into the output string after rendering since theme_file_icon doesn't give any options to do so.
Allowing users to add their own attributes also allows users to choose to make the icon "decorative" as described in the original post by passing the appropriate class names, etc.
Attaching a patch to make this function much more like theme_image while still allowing for default MIME values in the title field, etc. for others' thoughts.
Comment #77
mgiffordI think this would be better as a new issue for 8.1. Please start a new issue and link to it from here.
Comment #78
David_Rothstein CreditAttribution: David_Rothstein as a volunteer commentedI suspect it's not relevant for Drupal 8, but yes, a new issue for that sounds like a good idea.
It's an interesting proposal, but not directly related to this issue since all we were trying to do here was add the alt text, which is now done.
Comment #79
Daniel.Moberly CreditAttribution: Daniel.Moberly commentedI agree that its not relevant for Drupal 8 as the render array can be manipulated - the image tag is output directly in the function in Drupal 7.
New issue here: https://www.drupal.org/node/2594281
Comment #80
pfrenssenWhy was this committed without a test? This is now throwing notices in existing sites that call this theme function without supplying the 'alt' key.
See #2599180: Make alt and icon_directory properties really optionals.
Comment #81
pfrenssenThis got committed to both D7 and D8 without having test coverage.
Comment #82
David_Rothstein CreditAttribution: David_Rothstein as a volunteer commentedTests would definitely be nice. However, there shouldn't be any PHP notices unless you forgot to clear caches (or run update.php) when updating a site to the newest release. I'll comment on the other issue.
Comment #83
pfrenssen@David_Rothstein, you're correct, there are no notices thrown, #2599180: Make alt and icon_directory properties really optionals appears to have been caused by an incomplete core update.
Comment #84
fallenturtle CreditAttribution: fallenturtle commentedIs there a way to map multiple file extensions to a single text-alternative? For example the default array supplied in this patch seems to only catch .doc as a MS Word doc and not the newer .docx type. I'm assuming the same applies to all the other MS Office apps which have added "x" to the end of their extensions. Do I just need to add extra entries like so:
Or is it possible to be like (I know this isn't correct code):
Comment #89
fgjohnson@lojoh.ca CreditAttribution: fgjohnson@lojoh.ca commentedI don't want a a title tag at all.
Since he image is decorative;
The title tag and alt tag should be null so Assistive Technologies ignore the image.
https://www.w3.org/TR/WCAG20-TECHS/H67
Comment #90
andrewmacpherson CreditAttribution: andrewmacpherson as a volunteer commentedWCAG technique H67 isn't applicable here, because the file icon isn't merely decorative - it conveys meaningful information. It tells a sighted user "this is an audio file" (or a movie, or whichever). This information should be available to all users.
If the file icon were merely decorative, you could replace it with anything; like a house, a car, or a duck. Yet these wouldn't convey "audio file", in the way that headphones or a musical note would. Hence the choice of icon is meaningful, and not merely decorative.
The situation for file-type icons is best described by example 58 in the Icon Images section of the HTML5 recommendation. A good discussion of this can found in example 7 from the WebAIM alternative text article.
Comment #91
fgjohnson@lojoh.ca CreditAttribution: fgjohnson@lojoh.ca commented@andrewmacpherson
OK, Thanks...
I agree, the icon is important.
My concern is the mime-type title tag that seems unnecessary.
AT (screen reader) reads the title and the file path...
I don't think I need the mime "title" tag on every file link in a view.
Maybe I'm incorrect and the issue is that the tag should have a value.. not the
Comment #92
prachi.kadam CreditAttribution: prachi.kadam commentedComment #93
prachi.kadam CreditAttribution: prachi.kadam commentedPatch to support 'media/remote' mime type
Comment #94
prashant.kabade CreditAttribution: prashant.kabade as a volunteer and at Syngenta commentedPatch to support 'media/remote' mime type. Patch has applied & tested on 7.67Edit - test-failed . do not use this patch
Comment #95
prashant.kabade CreditAttribution: prashant.kabade as a volunteer and at Syngenta commentedAdding new based on testing results from #94
Comment #96
Nitesh Sethia CreditAttribution: Nitesh Sethia as a volunteer and at Syngenta commentedUpdated Patch.
Comment #97
Daniel.Moberly CreditAttribution: Daniel.Moberly commentedYou should open a new issue for whatever you're trying to solve here and explain the purpose of this new patch. I'm not sure what you're attempting to do here.