By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
426,011 Members | 1,000 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 426,011 IT Pros & Developers. It's quick & easy.

Image maps and area alt text

P: n/a
I have a simple question about the alt content of area elements
within an image map: is it redundant to include phrases such as
"link to..." or "jump to..."? My initial thought is 'yes', since
the area element implies a link to some other item or page location,
but would like to hear what others think.

If it helps at all, the page which prompted me to ask the question
is this one:

http://www.chem.utoronto.ca/courseno...s/summary.html

Be warned, however, that many of the actual links don't work yet;
I'm overhauling both the content and appearance of the original site,
and this is the parallel development version.
Jun 14 '07 #1
Share this Question
Share on Google+
6 Replies


P: n/a
David Stone wrote:
I have a simple question about the alt content of area elements
within an image map: is it redundant to include phrases such as
"link to..." or "jump to..."?
Ask yourself: what would you use if there were no image, just plain text
links?
http://www.chem.utoronto.ca/courseno...s/summary.html
Boy, I hope the users of this page have really good eyesight. It's
illegible to me.

--
Berg
Jun 14 '07 #2

P: n/a
Scripsit Bergamot:
David Stone wrote:
>I have a simple question about the alt content of area elements
within an image map: is it redundant to include phrases such as
"link to..." or "jump to..."?

Ask yourself: what would you use if there were no image, just plain
text links?
You could also view the page on Lynx, for example, which initially shows
(for the given page) "concept map" in place of the image. When selecting
(with the tab key and the enter key), this text - the alt text of the entire
image - acts in a link-like manner, opening a menu:

1. jump to
2. degrees of freedom
3. 1 or 2 tailed tests
4. jump to
5. t-test of 1 mean
etc.

So the answer is that "jump to" is redundant, and this is bad, because the
texts would have to be rather long anyway, and any extra words make it more
difficult to read them.

But the crucial question is what the alt texts are for and what they
contain. In an image map, the alt attribute should specify a textual
alternative to the _area_, not to the document that it links to. This is at
least the reasonable interpretation of the specification, which is somewhat
vague about alt attribute semantics. Thus, if an area content were the
formula "v = n", then it should have alt="v = n", no matter what the href
attribute points to.

Beware that alt attributes in area elements are poorly supported in graphic
browsers; see my page
http://www.cs.tut.fi/~jkorpela/html/mapalt.html
(fairly dated, but probably still the most extensive study of the issue).

So it might be a good idea to include a link to an alternative page that
contains the list of links without images.

Actually, I'm afraid that it is far from evident that there is something
clickable on screen when there's a client-side image map. There's nothing
that suggests such behavior, unless you start moving around the page with
the mouse and look at the status line or notice the "tooltips", if
displayed. If the texts on the left were blue with underlining, i.e. would
_look_ like links, it would be a different matter.
>http://www.chem.utoronto.ca/courseno...s/summary.html

Boy, I hope the users of this page have really good eyesight. It's
illegible to me.
Fair comment, but the image is already so wide that it's difficult to make
it fit on printing. (And it's something that users might really want to
print.) It's not very readable even on zooming, since the texts get rather
blurred.

It would be somewhat more readable if the image were reconstructed so that
the texts in it are in some sans-serif font - this might be a job for
Verdana, despite the fact that normal mathematical style doesn't use it.

I like the idea of using an image map this way, but I'm afraid that the poor
behavior of browsers makes this doubtful.

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

Jun 14 '07 #3

P: n/a
In article <4F******************@reader1.news.saunalahti.fi >,
"Jukka K. Korpela" <jk******@cs.tut.fiwrote:
Scripsit Bergamot:
David Stone wrote:
I have a simple question about the alt content of area elements
within an image map: is it redundant to include phrases such as
"link to..." or "jump to..."?
Ask yourself: what would you use if there were no image, just plain
text links?

You could also view the page on Lynx, for example, which initially shows
I hadn't thought of that, largely as I've never used it. It should be
possible to install it, though, since I'm using Mac.
(for the given page) "concept map" in place of the image. When selecting
(with the tab key and the enter key), this text - the alt text of the entire
image - acts in a link-like manner, opening a menu:
[snip]
So the answer is that "jump to" is redundant, and this is bad, because the
texts would have to be rather long anyway, and any extra words make it more
difficult to read them.
Well, that clears up one thing!
But the crucial question is what the alt texts are for and what they
contain. In an image map, the alt attribute should specify a textual
alternative to the _area_, not to the document that it links to. This is at
least the reasonable interpretation of the specification, which is somewhat
vague about alt attribute semantics. Thus, if an area content were the
formula "v = n", then it should have alt="v = n", no matter what the href
attribute points to.
Hmm. That's not quite how I interpreted section 13.6.1:

User agents and authors should offer textual alternates to graphical
image maps for cases when graphics are not available or the user
cannot access them. For example, user agents may use alt text to
create textual links in place of a graphical image map. Such links may
be activated in a variety of ways (keyboard, voice activation, etc.).

I think, in this case, the alt text has to be defined within the
context of the _function_ and _conceptual content_ of the image map,
not its specific appearance. In other words, what is the significance
of "v = n", and why would someone be interested on clicking on that
part of the map/that link?
Beware that alt attributes in area elements are poorly supported in graphic
browsers; see my page
http://www.cs.tut.fi/~jkorpela/html/mapalt.html
(fairly dated, but probably still the most extensive study of the issue).
Ok, fair enough. I have to admit that I was mostly adding the alt text
to suppress warnings when validating the page, but felt uncomfortable
simply using an empty string (alt="")
So it might be a good idea to include a link to an alternative page that
contains the list of links without images.
I'll have to think about that one - I have limited time right now, and
I am not immediately aware of any student who needs an alternative to
the visual presentation (although universal design principles suggest
it should be done at some point.)
Actually, I'm afraid that it is far from evident that there is something
clickable on screen when there's a client-side image map. There's nothing
that suggests such behavior, unless you start moving around the page with
the mouse and look at the status line or notice the "tooltips", if
displayed. If the texts on the left were blue with underlining, i.e. would
_look_ like links, it would be a different matter.
Point taken; on other image maps, there is a short introductory text
along the lines of "click on a part of the image for further details."
Like this one:

http://www.chem.utoronto.ca/courseno...hrom/hplc.html
http://www.chem.utoronto.ca/courseno...s/summary.html
Boy, I hope the users of this page have really good eyesight. It's
illegible to me.
Unfortunately, me too! I've been tweaking some of the other image
maps, and I'm aiming to do this one also. I can certainly make the
text within the first few rows bigger; the problem comes at the bottom.
Fair comment, but the image is already so wide that it's difficult to make
it fit on printing. (And it's something that users might really want to
print.) It's not very readable even on zooming, since the texts get rather
blurred.
Note to self: I should make sure there's an @media print that hides the
navbar!
It would be somewhat more readable if the image were reconstructed so that
the texts in it are in some sans-serif font - this might be a job for
Verdana, despite the fact that normal mathematical style doesn't use it.
I'll have to give that a try when I update the original image.
I like the idea of using an image map this way, but I'm afraid that the poor
behavior of browsers makes this doubtful.
Unfortunately, I'm not wild about any of the alternatives for something
this complex. I have seen organizational charts done quite nicely
(such as the Elvish Genealogy), but those haven't been as deep, and
didn't require embedded equations!
Jun 15 '07 #4

P: n/a
Scripsit David Stone:
I think, in this case, the alt text has to be defined within the
context of the _function_ and _conceptual content_ of the image map,
not its specific appearance. In other words, what is the significance
of "v = n", and why would someone be interested on clicking on that
part of the map/that link?
My example was actually based on my wrong initial guess on what might be the
active areas of the image map. I expected the bordered boxes, rather than
the texts on the left, to be such areas. I then realized what the idea was.
But there was really nothing in the visual appearance suggesting it; this is
one of the problems with image maps.

But _assuming_ that a box with "v = n" in it _were_ an active area (a link),
then I still think that the correct alt text, both functionally and by the
letter and spirit of the specification, would be alt="v = n". The point is
that the alt text is supposed to specify the textual equivalent of the
_area_.

You can look at this from another perspective too. A person who sees the
image map and its areas will base his decisions on what he sees in the area,
such as the text "v = n". Therefore, a person who accesses the page in a
different mode, should normally have the same text available. (If an area
contains "rich text" with superscripts and italics etc., it may be necessary
to consider how to present the equivalent information in plain text, as
required by HTML rules for attribute values.)

Of course, in some cases, the equivalent text would need to be something
different, but this would depend on the visible map, not on the pages it
links to. It's the visual information in the map and its areas that needs
textual equivalents. For example, if
>Actually, I'm afraid that it is far from evident that there is
something clickable on screen when there's a client-side image map.
- -
Point taken; on other image maps, there is a short introductory text
along the lines of "click on a part of the image for further details."
That's one of the few situations where the word "click" makes sense on web
pages. Normally I (and the W3C) oppose "clickism", but here some reference
to the technicalities might be needed. But perhaps it _could_ be formulated
in a more device-agnostic way, e.g. "The bordered parts of the image are
links to further details". Assuming that the active areas have borders, I
think that would do well. People using the page without images would have no
use for the information about borders, but neither would they need it, since
their browser is effectively expected to present the image map as a list of
textual links. So it's really in the visual mode where users need hints!

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

Jun 15 '07 #5

P: n/a
In article <T9*******************@reader1.news.saunalahti.fi> ,
"Jukka K. Korpela" <jk******@cs.tut.fiwrote:
Scripsit David Stone:
I think, in this case, the alt text has to be defined within the
context of the _function_ and _conceptual content_ of the image map,
not its specific appearance. In other words, what is the significance
of "v = n", and why would someone be interested on clicking on that
part of the map/that link?

My example was actually based on my wrong initial guess on what might be the
active areas of the image map. I expected the bordered boxes, rather than
the texts on the left, to be such areas. I then realized what the idea was.
But there was really nothing in the visual appearance suggesting it; this is
one of the problems with image maps.
Actually your assumption was correct, I just don't have all the areas and
links defined on that particular version of the page yet. As I said, I'm
updating both the content and presentation of an existing site, and
putting the revised material in a parallel site for testing purposes as
I get each page finished.
But _assuming_ that a box with "v = n" in it _were_ an active area (a link),
then I still think that the correct alt text, both functionally and by the
letter and spirit of the specification, would be alt="v = n". The point is
that the alt text is supposed to specify the textual equivalent of the
_area_.
I understand that; I'm still thinking through some of the ramifications
of using an image map (who's primary purpose is presumably navigation)
as a concept map (with links to related information). I think it would
be fair to say that this is a little beyond the "simple" use envisioned
in the html specs.

[snip]
Actually, I'm afraid that it is far from evident that there is
something clickable on screen when there's a client-side image map.
- -
Point taken; on other image maps, there is a short introductory text
along the lines of "click on a part of the image for further details."

That's one of the few situations where the word "click" makes sense on web
pages. Normally I (and the W3C) oppose "clickism", but here some reference
to the technicalities might be needed. But perhaps it _could_ be formulated
in a more device-agnostic way, e.g. "The bordered parts of the image are
links to further details".
I hadn't thought of that, but can area elements have visible borders?
I don't see any mention of that in the specification, but it does
list onfocus an onmouseover, so you could have some sort of highlighting.
Can hover be applied here as an alternative?
Jun 15 '07 #6

P: n/a
Scripsit David Stone:
I hadn't thought of that, but can area elements have visible borders?
I meant areas with borders in the sense that the image of the image map
contains them. That is, the borders would be added when creating the image.

Technically, an area element, like any element, has the CSS border
properties, but I don't expect browsers to take them into account when
presenting a document.
I don't see any mention of that in the specification, but it does
list onfocus an onmouseover, so you could have some sort of
highlighting. Can hover be applied here as an alternative?
Well, highlighting on mouseover does not really help with the problem that a
user does not recognize an image as "clickable" or its active areas.

Browsers tend to show a 1px dotted or dashed _outline_ when an area is
clicked, similar to the "selection rectangle" of normal links. This does not
help much (many authors even regard it as a nuisance!), though.

Highlighting on mouseover is possible but only by using an onmouseover event
handler for an area element, with code that replaces the entire image with a
version that has the particular area highlighted. So it takes quite some
work to set things up that way, and there's performance overhead (especially
if the image is large), so it's rare.

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

Jun 15 '07 #7

This discussion thread is closed

Replies have been disabled for this discussion.