Recently Roger Johansson wrote a post about Safari, WebKit and alt text for missing images. In which he talks about how Webkit based browsers do not always display alt attribute content in place of an image when the image is not available or images are disabled. I have gone a little further into this issue by testing what is displayed with differing combinations of the alt and title attributes on images in IE, Firefox, Opera, Chrome and Safari.
Results summary
- All browsers tested display the content of the alt attribute as text, if the image is missing or images are disabled, with the following exceptions:.
- Opera truncates the display of text if it is longer than the
imgwidth. - Chrome and Safari do not display the text if it is longer than the
imgwidth.
- Opera truncates the display of text if it is longer than the
- All browsers except Firefox render an area equal to the
imgdimensions. - IE, Chrome and Safari always display an icon and border.
- Chrome and Safari (only) display the content of the
titleattribute as text if thealtattribute is not present. - Chrome and Safari (only) the display of
titleattribute content is suppressed if an emptyaltattribute (alt="") is present. - Opera displays the text “image” if images are not available and the
imgdoes not have analtattribute.
Results Screenshots
A page with screenshots of the test images in each of the browsers tested is available.
Results Details
A table containing detailed results can be found on the test page.
Discussion
The results reveal a lack of standardized display behaviour across browsers, which makes it difficult for authors to provide a predictable experience to users in cases where images are not available or users have disabled the display of images to suit their requirements. It would be useful if the recommended behaviour was clearly specified in the HTML5 specification, the current wording is not precise, which will result in a continuation of the current diversity of implemented aproaches.
Comments
thanks for the research — one consideration of the current failure of @title as an accessibility tool is due in large part to a lack of support on the assistive technology side; i can set my screenreader to read title instead of hyperlink text but cannot use it as a filtering criterion, nor can i toggle between meta-data provided for a link with a series of hot-key combinations, each following a user-defined cascade order for exposing meta-data defined inline for a link (link text, title, href for links; alt, title, longdesc, src for graphical links) so that i can have them exposed via direct query; currently, i am limited by the screen readers available to me to either have link text or title text (or the longest of the 2) exposed; obviously, setting a screen reader to read title values rather than hyperlink text can severely disrupt the reading order during speak-all, causing congnitive dissonance; what users need is the ability to list links by title & toggle back & forth between hyperlink text & title text & any other CDATA provided for the link, AND for the assisitive technology to provide a query command for hyperlink text and another for title or other CDATA using same keycombo — the second press gets title, third press @href value, etc.)
Thanks for the article Steve and for the comment Greg. Although the thrust of Roger and Steve’s articles is about the way browsers handle title attributes, I agree with Greg that the way different ATs handle the title attribute is a significant issue, particularly if setting to render title will turn off rending the alt. Also, I am not sure how many screen reader users are very familiar with changing the verbosity settings – perhaps not as many as we sometimes think.
yes i feel likewise, this post was not meant to tackle that issue, it was about the visual display of the alt and title in browsers.
Quite interesting. I’ve noticed the differences a long time ago, but I never had the nerves to make actual tests.
As a slight remark to your results, Fx actually makes the image the same height as the inherited line height and zero pixels wide. It’s best visible when you put a border.
Also, when you change the display property of the image to be other than inline — inline-block or block per say — then the dimensions do get applied. That might be appropriate for a quick and dirty hack. Even IE 6 will acknowledge it. (Alas not Fx 2.)
In the same vicinity of “interesting”-ness is what happens when you hover an image with an @alt and an image with a @title. Unsurprisingly, browsers behave differently as well.