E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 2 (In chronological order)

From: Jukka Korpela
Date: Tue, Jun 18 2002 10:53PM
Subject: RE: image maps & browser (in)compatibility
No previous message | Next message →

Judy Thai wrote:

> I'm working on making our organizational chart a client-side
> image map, and I've been having some trouble with the ALT tags
> showing up in NS6+ and Mozilla

When I tested Netscape 6.1 (more exactly, Mozilla/5.0 (Windows; U; Win98;
en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1) in no images mode (Edit >
Preferences > Privacy and Security [!] > Images, check "Do not load any
images") I was really shocked.

Nothing. Void. Nihil. Nada.

Netscape 6.1 shows an empty area where the image would appear, with
dimensions as specified by the width and height attributes. There is no
other indication but the empty area that any image might be involved. Except
if the user moves the cursor over it. Then the value of the title [!]
attribute appears in a "tooltip" window.

This happens for normal <img> elements too. For image maps, the only
difference is that the "tooltip" is taken from the <area> elements where
applicable.

As if this were not odd enough, if image loading is enabled in Netscape 6
but the image is nonexistent, Netscape shows the <img> element's alt text
properly. It also displays it as a "standby" text while waiting for the
image to load; you usually need a slow connection to see this.

So what's broken is simply the way Netscape 6 implements switching images
off: it behaves as if the user had requested the browser to _ignore_ <img>
elements.

> <IMG SRC="image.gif" ALT="alt tag for image" BORDER="0"
> USEMAP="#orgchart">
>
> <MAP NAME="orgchart">
> <AREA SHAPE="RECT" ALT="John Doe" TITLE="John Doe"
> COORDS="5,10,15,20"
> HREF="john_doe.html">
> </MAP>

The markup is OK, as far as I can see (as a pattern). The Netscape 6 browser
is not.

On the other hand, even before this I had deduced that an image map should
always be accompanied with "redundant" links or, to put it in another way,
an author should use normal link elements for linking and consider image
maps only as _alternatives_. For the reasons behind this conclusion, see
http://www.cs.tut.fi/~jkorpela/html/mapalt.html
(For an orgchart, a suitable presentation could be nested lists of links,
with the nesting of <ul> elements reflecting the levels of the organization.
Admittedly, it easily becomes visually large, so one might put a link to it
onto the primary page, right before [!] the image map.)

Image maps themselves can be very useful, for accessibility too, e.g. for
helping people who work visually much better than with text. But in the
current situation, especially with the poor and even faulty implementations
of image maps in browsers, there's no smooth way of using a single construct
that works as an image map in visual presentation and as textual links
otherwise. (It's the "graphic" browsers that are the problem here, not
"text" browsers like Lynx.)

--
Jukka Korpela, senior adviser
TIEKE Finnish Information Society Development Centre
http://www.tieke.fi
Phone: +358 9 4763 0397 Fax: +358 9 4763 0399


----
To subscribe, unsubscribe, or view list archives,
visit http://www.webaim.org/discussion/

From: Leo Smith
Date: Thu, Jun 20 2002 5:21AM
Subject: RE: image maps & browser (in)compatibility
← Previous message | No next message

To add to this, Google does not spider image map links. So if you
have an image map linking to crucial pages, you are gonna want to
also have redundant text links that Google can spider.

Leo.

>
> On the other hand, even before this I had deduced that an image map
> should always be accompanied with "redundant" links or, to put it in
> another way, an author should use normal link elements for linking and
> consider image maps only as _alternatives_. For the reasons behind
> this conclusion, see http://www.cs.tut.fi/~jkorpela/html/mapalt.html
> (For an orgchart, a suitable presentation could be nested lists of
> links, with the nesting of <ul> elements reflecting the levels of the
> organization. Admittedly, it easily becomes visually large, so one
> might put a link to it onto the primary page, right before [!] the
> image map.)
>
> Image maps themselves can be very useful, for accessibility too, e.g.
> for helping people who work visually much better than with text. But
> in the current situation, especially with the poor and even faulty
> implementations of image maps in browsers, there's no smooth way of
> using a single construct that works as an image map in visual
> presentation and as textual links otherwise. (It's the "graphic"
> browsers that are the problem here, not "text" browsers like Lynx.)
>

>



Leo Smith
Web Designer/Developer
USM Office of Publications and Marketing
University of Southern Maine
207-780-4774


----
To subscribe, unsubscribe, or view list archives,
visit http://www.webaim.org/discussion/