alt and title content display in popular browsers

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 img width.
    • Chrome and Safari do not display the text if it is longer than the img width.
  • All browsers except Firefox render an area equal to the img dimensions.
  • IE, Chrome and Safari always display an icon and border.
  • Chrome and Safari (only) display the content of the title attribute as text if the alt attribute is not present.
  • Chrome and Safari (only) the display of title attribute content is suppressed if an empty alt attribute (alt="") is present.
  • Opera displays the text “image” if images are not available and the img does not have an alt attribute.

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.

Categories: Technical

About Steve Faulkner

Steve was the Chief Accessibility Officer at TPGi before he left in October 2023. He joined TPGi in 2006 and was previously a Senior Web Accessibility Consultant at vision australia. Steve is a member of several groups, including the W3C Web Platforms Working Group and the W3C ARIA Working Group. He is an editor of several specifications at the W3C including ARIA in HTML and HTML Accessibility API Mappings 1.0. He also develops and maintains HTML5accessibility and the JAWS bug tracker/standards support.

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

roger says:

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.

joneff says:

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.