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:
- Using mouse events for the image: when
onMouseOver
is triggered, swap out the existingalt
text and set thealt
to an empty string, then reinstate the originalalt
text whenonMouseOut
is triggered. - Override the tooltip that appears as a result of the
alt
text by ensuring atitle
attribute is set on the image — an emptytitle
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:
- Why doesn’t Mozilla display my alt tooltips?
- alt as a tooltip by Anne van Kesteren
- Alt text is an alternative, not a tooltip by Roger Johansson
- Should the “alt” attribute be used for tooltips? by Ian Hickson
- My take on the alt attribute and tooltips by Jeff Croft
On alt
attributes and alternative text:
- The alt and title attributes – a good introduction to the
alt
andtitle
attributes by Roger Johansson - Writing good ALT text by Simon Willison
- Appropriate Use of Alternative Text over at WebAIM
- The Alt and Accessibility – another good introduction to
alt
attributes and discussion of appropriate usage by Mike Cherim
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 Responses to “Removing alt tooltips in IE with JavaScript”
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.
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.
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.
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.
Cool! I hate tooltips, I’m definitely looking into this!
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 foralt
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.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.
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: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.
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 emptyalt
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.
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 thealt
is different to what the user sees, activating that link becomes problematical. Optimalalt
text in this case would be “UKOS plc (home)” or similar.