IE 8: alt change and longdesc weirdness

Update for IE 8b2

I have updated the results for IE8 b2, and included tests for input type=”image”

  • Tests and results for HTML 4.01 transitional.
  • Tests and results for HTML 4.01 strict.

update end.


Reading through the What’s New in Internet Explorer 8, this caught my attention:

The alt attribute is no longer displayed as the image tooltip when the browser is running in IE8 mode. Instead, the target of the longDesc attribute is used as the tooltip if present; otherwise, the title is displayed. The alt attribute is still used as the Active Accessibility name, and the title attribute is used as the fallback name only if alt is not present.

So IE 8 falls into line with the HTML 4.01 specification and other major browsers in regards to not using alt attribute content as a tooltip – good news.

Then it starts to get strange “instead the target of the longdesc attribute is used as the tooltip if present“. So now we have support for longdesc in IE8?? But how is that going to work… Does the tooltip show the text content of the target file? Does it show structure and formatting?

Just when it was thought that the longdesc had been assigned to HTML heaven, Microsft have decided to support it…

Testing support

To test out the changed alt and added longdesc support a test page with some combinations of alt, longdesc and title was created.
The results were mixed:

  • The alt is not displayed as a tooltip when using HTML 4.01 strict DOCTYPE or XHTML DOCTYPE’s.
  • The alt is displayed as a tooltip when using a HTML 4.01 transitional DOCTYPE.
  • The longdesc attribute target URI content is not displayed as a tooltip as stated in the documentation.
  • The URI contained in the longdesc attribute is included in the MSAA Description property ((accDescription) information about the control that doesn’t fit into any other field). In previous IE versions it was not.

So the implemenation of the longdesc is not complete (or perhaps the testing is at fault), but clearly something is going on with the longdesc in IE8 as evidenced when you look under the hood at the MSAA information.

Note:

Having re-read the documentation and discussed it with my colleague Gez Lemon who pointed out to me my mis-interpretation of the mircrosoft documentation: The URI will be displayed as a string in the tooltip, not the content of the URI as I interpretated it as initially. this would explain the URI being in the MSAA Description property.

Categories: Technical
Tags: ,

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

Bim says:

Oh botheration! It’s nice of Microsoft to care, but clear that they need to think through the decision on LONGDESC before it’s implemented. As a LONGDESC value is only a link to a long description page, which might contain an entire table of financial data, the idea of a tooltip is decidedly scary.

Even at the most basic practical level, it’s unlikely that a tooltip will be any good to anyone. People who can’t see a complex image well enough to understand it, are equally unlikely to be able to read a long tooltip. Under screen magnification, most of it may be off the screen view, and at normal screen view the text is likely to be too small to read. Then, as you say, the chances of transfering meaningful structure from the long description page to a tooltip, seem remote.

What we really need for the LONGDESC attribute, if it’s to survive and be useful, is a means of accessing it via the keyboard for all users, not just people with screen readers. Plenty of users have vision problems that aren’t severe enough to require a screen reader, but are too severe to be able to process complex information portrayed in an image. Then there are users with no vision problems at all, but who are using small screens or find images difficult to understand, they too could do with a route to the long description.

This is an issue that was brought up in the HTML 4.01 specification, but as far as I know, there are no browsers that have yet met this challenge. Could Microsoft be the first?

In the meantime, how do you feel about asking web authors to provide an adjacent meaningful text link to the long description of complex images Steve?

Bim says:

After your amends: well if only the URI will be displayed in the tooltip, at least there won’t be the challenge of reading a long description in 5 seconds. But I’m still not sure that it will be of much value, unless there’s a mechanism for opening the target file for everyone. There’d also need to be a way for keyboard only users to identify which images had long descriptions. A mechanism that didn’t rely on the mouse hover.

Stevie D says:

It seems utterly bizarre and backwards to prefer the longdesc URI to the title, but that’s what the documentation reads like to me – if you’ve got a longdesc, that will appear in the tooltip and the title won’t.

It seems like longdesc needs to curl up and die. It has never worked properly – very few authors know about it, very few of those use it, a miniscule proportion of users have ever heard of it, no mainstream browser (as far as I’m aware) provides any means to activate it – dead and gone.

If we can now use [object] tags to include images and provide rich alternative text (including a link to further description, where necessary), the need for longdesc seems to have gone away. Yes, it is slightly more compact, but far less elegant and effective than [object].

hi zcorpan,
thanks for the info, will add results for other tests, I had observed that the alt on the input was still displayed as a tooltip, but had not gotten around to adding this result and had not tested the area element.

Latest IE8 says:

This behavior seems to be gone in the latest build of IE8. Only the title attribute gets displayed as a tooltip.