dotjay.co.uk

Internet Explorer alt tooltips 24 April 2007 : Removing alt tooltips in IE with JavaScript

There was a bit of debate on Anne van Kesteren’s blog last year about alt attributes being rendered as tooltips by some Windows browsers, most notably, Internet Explorer.

Following the W3C specifications, there’s no reason for alt attributes to appear as tooltips. However, there’s nothing to say that ‘alt tooltip’ behaviour is wrong. Certainly, alternative text should appear if an image does not render on the page.

Working on a recent project, the client asked why the descriptive alternative text for an image appeared when they moused over the header image that spanned the top of each page of content. They wanted the alternative text to either not appear or be set to text optimised with keywords.

Update: When first writing this article I was under the impression that screen readers would announce all images followed by their alternative text. Consequently, I’d put alternative text in for all images in markup because I’d personally prefer to be told, “Hey, this image is of an old oak tree with twisted branches” than “There’s an image here, but we don’t want to tell you what it’s in it”! I’ve since found out that JAWS will not even announce the presence of an image that has an empty alt attribute. If that behaviour can be relied upon in all screen readers, the most appropriate solution to our problem may have been to leave the alt blank. I think the JavaScript solution I provide below is still useful should you wish to get Internet Explorer to present correct tooltip behaviour.

What could we do?

The alt text was fit for purpose and we refused to bend the rules for the sake of a bit more SEO. So, we wanted to keep the alternative text but override the tooltip behaviour in Internet Explorer.

Setting an empty alt would have removed the tooltip, but at the expense of accessibility. That’s the obvious option out the window.

Before I go any farther, I thought I’d better point out that alt attributes are a good thing and are required for all images in markup. If you are reading this thinking otherwise, I highly recommend that you read up on appropriate use of alt attributes.

Another option was to add the image as a background with CSS, as it could have been considered a decorative image. Being so close to project finish, we didn’t want to have to go through the site making all the images backgrounds. We also wanted these images to stretch with increases in text size. Next option down.

Internet Explorer will correctly display the contents of a title attribute as a tooltip when one is set on an element. Rather conveniently, an empty title attribute overrides Internet Explorer’s ‘alt tooltip’ behaviour but does not show a tooltip. However, we can’t be sure this will happen in all browsers and I don’t like to muddy my markup.

We opted for an unobtrusive JavaScript solution. This keeps the solution in the behaviour layer and allows us to sniff out Internet Explorer.

Enter the JavaScript

I came up with two JavaScript solutions:

  1. Using mouse events for the image: when onMouseOver is triggered, swap out the existing alt text and set the alt to an empty string, then reinstate the original alt text when onMouseOut is triggered.
  2. Override the tooltip that appears as a result of the alt text by ensuring a title attribute is set on the image — an empty title attribute doesn’t display a tooltip in Internet Explorer, but does override the ‘alt tooltip’ behaviour for us.

The latter was preferential as it didn’t seem to have any immediately obvious accessibility issues.

A bit of a disclaimer: I don’t recommend overriding any behaviour unless you really have a need to do so. I used this solution in a selective manner. If you intend to use JavaScript to override behaviour in any significant way, consider providing client-side options so that users can set a preference.

So, without further ado, here’s the code I used. Feel free to use it, share it, suggest improvements or provide your insight on tooltips displaying alt text.

var objFixIeTooltip = {
	// methods
	init : function() {
		// detect support
		if (!document.getElementById || !document.getElementsByTagName) return;
		// detect IE - leave out if using conditional comments
		var isIE = navigator.userAgent.indexOf("MSIE");
		if (isIE < 1) return;
		// find the image(s) - tweak to your needs
		var elContainer=document.getElementById("header");
		if (!elContainer) return;
		var elImg=elContainer.getElementsByTagName("img")[0];
		if (!elImg) return;
		// if there isn't already a title attribute set on the image, set the title attribute to blank, thus overriding the alt tooltip behaviour
		// use == '' because IE always thinks title is a string (cannot distinguish between undefined and empty attributes)
		if (elImg.getAttribute('title') == '') elImg.setAttribute('title','');
	}
};
addLoadEvent(objFixIeTooltip.init);

Of course, to avoid using browser detection within the script, you could leave it out and include the script using conditional comments:

<!--[if IE]><script type="text/javascript" src="path/fixIEtooltip.js"></script><![endif]-->

References and reading

On alt tooltips:

On alt attributes and alternative text:

You can find more on alt attributes and alternative text in my del.icio.us bookmarks.

And just for fun – I love this: Wheee!

11 Comments

Comment 1

The accessibility issue here is that you’re messing with user expectations.

The alt-tooltip behavior may be wrong, but it’s common expectation, and by suppressing or removing that behavior you’re messing with expectation among IE users.

Not a big thing, but I would have stood firm and told the client “no”. If they really don’t like the alt text appearing, then choose some suitable title text – something which is applicable and adds information.

James Edwards, 25 April 2007 at 0217

Comment 2

I think it’s an outstanding contribution. If I want a “tool tip” I’ll use the title attribute and let the alt attribute be what it is. IE’s the only browser I know of that screws it up so this should ensure that all JavaScript-enabled browsers are on the same page so to speak. Nice one Jon.

Mike Cherim, 25 April 2007 at 0322

Comment 3

James: Jon wrote this to specifically meet user expectations in IE, as odd as that may sound.

To explain, the site in question has header text over an image. The image effectively functions visually as a background to the header. In the actual use case in question the header text contains a link. When moving to that link the user would anticipate any tooltip text to be related to the link. The alternative text is not, and so confused people in user testing.

We’d already issued a “no” in response to the client request to change the alternative text to be non-descriptive and effectively keyword packed. After testing, this seemed like the best option to: 1. Remove the confusion, and 2. Still retain descriptive alternative text.

For what it’s worth, this decision wasn’t taken lightly, and the technique seemed like the best option to retain alternative text and satisfy user expectations in context.

Jon Tan, 25 April 2007 at 1117

Comment 4

Thanks guys.

@ James: As you say, it’s not a big thing, but as Jon T explains, removing the alt tooltip behaviour may actually relieve potential confusion in some contexts.

For some users, the tooltip behaviour may even be annoyingly in the way. In which case, perhaps the best solution would be to give the user the option of turning off the behaviour? Unfortunately, it’s not yet an option in IE’s settings.

Letting my mind wander a little here: if browsers can change fundamental aspects of their interface between releases, how come manufacturers argue that certain behaviours (e.g. alt tooltips in IE) should persist? Can these not at least be made configurable?

@ Mike: Bear in mind that the code I gave here is an example and would need to be tweaked to override the behaviour for all images on a page.

dotjay, 25 April 2007 at 1153

Comment 5

Cool! I hate tooltips, I’m definitely looking into this!

Jen, 01 May 2007 at 0110

Comment 6

Just to be clear, I do not advise or advocate disabling tooltips in general. That level of control is really a job for browser preferences. You shouldn’t force that on users.

Tooltips appearing for title attributes is expected behaviour. By displaying tooltips for alt attributes, Internet Explorer is not following the W3C standards. The purpose of this JavaScript was to counter that incorrect behaviour in a selective manner. Ideally, I would also add an option in a site’s preferences to switch this overriding behaviour on or off.

dotjay, 02 May 2007 at 1755

Comment 7

We had a site with a series of menu link images. Following specification, each image has an alt attribute, which IE turned into tooltips. We left out the title because the tooltip cannot be controlled and it would cover up information displayed to the user in a larger, bolder font (we cater to people with many disabilities, including vision-impaired). The information in a static location changes depending on where the user hovers, but we needed to disable the tooltip to prevent the information from being covered. Expected by users or not, we had a custom scenario and should have the right to disable tooltips in such situations. As it stands, I had to replace the title tags with empty “” just to sidestep IE thinking it knows better than the designer.

Ryan Dagey, 06 July 2007 at 2109

Comment 8

Thanks Ryan.

Although there are arguments against using image-based menus (e.g. they don’t necessarily cope with changes in font-size), it’s good to show that Internet Explorer’s alt tooltip behaviour could actually cause accessibility issues.

I came up with this JavaScript solution in preference to adding empty title attributes to my markup because:

  1. It’s a behavioural issue, so a solution in the behavioural layer of JavaScript made sense.
  2. I could ‘detect’ Internet Explorer to serve the fix only when appropriate.

dotjay, 08 July 2007 at 1105

Comment 9

First, your site looks really accessible, which is great. A quick run around it with WebbIE, the web browser I develop for blind people, suggests it works really well.

However, I disagree with you on the alt attributes. Let’s suppose I’m a blind guy, and in a moment of madness I’ve turned on images in my screenreader. Your site has an image alt tag of “A single tree standing out in a canola field”. I’m on a site about stationery: how is this helping me decide which of the 38 links to follow? It’s not. An empty alt attribute, alt=”“, would have been better.

You have two other alt attributes: for the Home link (which should be “Home” rather than “UKLOS Logo”. Is it a link to the UKLOS Logo? No, it’s a link to the home page) and the Search link (perfect, “Search”) Since you’ve defined title attributes for Home and Search you clearly did want tooltips to appear in these situations.

So, you could have obviated the need for your technique by simply using alt=”“, and produced an easier-to-use more accessible website into the bargain!

More generally, the best solution for IE showing tooltips is to use more empty alt attributes. A blind guy will generally welcome smaller, simpler websites, just like sighted people like websites without animations and splash screens. For blind people, a beautiful design is about good copy and great usability, not knowing you used a lovely picture of a tree.

Alasdair King, 16 August 2007 at 1517

Comment 10

Thanks for your comment, Alasdair.

Personally, I think that any image in markup should have alt text specified, unless adding it entails duplication of text. All the screen readers I know of will announce an image in the markup, so I believe there should be a short description of what that image is. For me, I’d prefer to be told “Image: A single tree standing out in a canola field” than to be told nothing at all. Update: Having said that, I've since found out that JAWS will not even announce the presence of an image that has an empty alt attribute. If that behaviour can be relied upon in all screen readers, perhaps an empty alt may have been appropriate in this case.

Granted that the image in question is for decoration, which should be in CSS. However, we decided to make that image stretch with the site’s elastic layout, thus catering for people who need to up the text size without breaking the site design. Web accessibility is not just about accommodating blind people.

dotjay, 29 August 2007 at 1126

Comment 11

Alasdair, your recommendation regarding the link back to the home page on the logo is made with only screen reader users in mind.

Consider a person using voice recognition software such as Dragon Naturally Speaking. In order to activate links, the software uses the alt attribute as the trigger phrase. If the alt is different to what the user sees, activating that link becomes problematical. Optimal alt text in this case would be “UKOS plc (home)” or similar.

dotjay, 15 September 2007 at 1220

Commenting is closed for this entry, but please contact me to share your thoughts.

Jon Gibbins is a web developer and accessibility geek; dotjay.co.uk is his online home.

Associating

Site Information

dotjay.co.uk is published with Textpattern. There are feeds.

Copyright

© 2004–2008 Jon Gibbins (dotjay). Some rights reserved.

Except where otherwise noted, content on this site has a Creative Commons License.