Image/Object Maps Accessibility

[Stanimir Stamenkov]

I have this kind of construct:

http://www.geocities.com/stanio/temp/usemap01.html

(an IMG element using MAP described with AREA elements)

I'm trying to make it more accessible and currently I'm testing in
Lynx. Lynx plays it clever and when I "enter" the map it shows only
3 links no matter there are 5 AREAs (3 point to a same reference). I
don't like Lynx displays the 'alt' text and not the link titles
(I've used slightly different titles for the 3 links which point to
a same reference for testing purposes, but they should really be
the same).

So to make it more accessible in Lynx I've tried:

http://www.geocities.com/stanio/temp/usemap02.html

an OBJECT element using and enclosing MAP described with A
elements, so Lynx would display the links in-document and not
separately. But then I don't want the duplicate reference links to
appear - this is my primary goal.

Something which is not very clear for me:

http://www.w3.org/TR/html401/struct/...de_image_map-1

Can I combine block-level content included A elements with AREA
elements? The spec states:

When a MAP element contains mixed content (both AREA elements and
block-level content), user agents must ignore the AREA elements.

which in turn means (to me) that in graphical browsers showing the
image/object the additional areas specified with AREA wouldn't be
active... ?

In fact the different browsers I've tried (Netscape/Mozilla, IE and
Opera) behave very strange in such situation. Here are other test
cases for this (including when the MAP is outside the OBJECT):

http://www.geocities.com/stanio/temp/usemap03.html
http://www.geocities.com/stanio/temp/usemap04.html
http://www.geocities.com/stanio/temp/usemap05.html
http://www.geocities.com/stanio/temp/usemap06.html

Only Opera unifies As and AREAs. For Netscape/Mozilla there's
different behavior if I put AREAs first or the As first. IE is hopeless.

I'm confused about what is right and what approach I should take.

--
Stanimir

[Jukka K. Korpela]

Stanimir Stamenkov <s7****@netscape.net> wrote:

(an IMG element using MAP described with AREA elements)
The short answer to image map accessibility is "no, it isn't". There's
really just one excuse, or actually a reason, to use a client-side image
map: when a selection to be made by the user is inherently two-dimensional,
such as selecting an area from a real map, or selecting an object from a
photo. Even then, a redundant list of links should be added, i.e. the image
map should only be provided as an _alternative_. This is an explicit
requirement in Section 508 rules, and it is also presented as an "until user
agents..." rule in WAI guidelines. For an explanation why it's still
relevant, and will be for a long time, see
http://www.cs.tut.fi/~jkorpela/html/mapalt.html

(Server-side image maps should only be used for special applications that
cannot be implemented otherwise, such as a map service where you can click
on any location and have a new map with that location in the center.)
I'm trying to make it more accessible and currently I'm testing in
Lynx.
Lynx is too good. Try with IE with images disabled.
I don't like Lynx displays the 'alt' text and not the link titles
It's the alt text that is by definition what the author provides as
ALTernative text.
an OBJECT element using and enclosing MAP described with A
elements,
The OBJECT element is almost useless due to horrendously buggy
implementations. When used for image maps, it makes things much worse.
I'm confused about what is right and what approach I should take.

First design the page without any image maps. Then consider adding an image
map as an alternative. The choice should be based on a simple question: will
this help users? For example, if it's a matter of selecting a US state in
order to get info about a company's activities in that state, then a map
which is an image map (with states with no activities greyed out somehow)
would probably make things somewhat easier to many users, since they could
see the situation easily and make a choice fast, as compared with selecting
a name from a list of links. But you should still have that list somewhere.

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

[Stan Brown]

In article <Xn*****************************@193.229.0.31> in
comp.infosystems.www.authoring.html, Jukka K. Korpela
<jk******@cs.tut.fi> wrote:

For example, if it's a matter of selecting a US state in
order to get info about a company's activities in that state, then a map
which is an image map (with states with no activities greyed out somehow)
would probably make things somewhat easier to many users, since they could
see the situation easily and make a choice fast, as compared with selecting
a name from a list of links.

Might I offer a dissenting view?

A list in a form downloads to my computer faster than almost any
image large enough to show 50 US states (or even 48 US states).

My own preference is for the list, because I can select my state and
be on the next page already, before the image has finished
downloading.

As you say, it is good to offer both alternatives.

--
Stan Brown, Oak Road Systems, Cortland County, New York, USA
http://OakRoadSystems.com/
HTML 4.01 spec: http://www.w3.org/TR/html401/
validator: http://validator.w3.org/
CSS 2 spec: http://www.w3.org/TR/REC-CSS2/
2.1 changes: http://www.w3.org/TR/CSS21/changes.html
validator: http://jigsaw.w3.org/css-validator/

[Stanimir Stamenkov]

Jukka K. Korpela wrote:

The short answer to image map accessibility is "no, it isn't". There's
really just one excuse, or actually a reason, to use a client-side image
map: when a selection to be made by the user is inherently two-dimensional,
such as selecting an area from a real map, or selecting an object from a
photo.
Actually this would be a part of a device documentation where there
are two sections (using this technique): Front and Rear View, each
starting with a front/rear view picture/scheme to be used as visual
TOC with links pointing to sections describing the corresponding
parts. Does it make sense to use image maps?
Even then, a redundant list of links should be added, i.e. the image
map should only be provided as an _alternative_.
That's why I'm trying a MAP with A elements.
This is an explicit
requirement in Section 508 rules[...]
OT: I wish there is such section in my country's laws too.
(Server-side image maps should only be used for special applications that
cannot be implemented otherwise, such as a map service where you can click
on any location and have a new map with that location in the center.)

I don't find use of server-side maps other than mentioned above. I
don't need nor I plan using server-side maps. The documentation
would be stand-alone.

I don't like Lynx displays the 'alt' text and not the link titles

It's the alt text that is by definition what the author provides as
ALTernative text.

O.k., whatever. Did you notice that Lynx renders the 'title's in the
last two examples and not the 'alt'? (I don't know why)

an OBJECT element using and enclosing MAP described with A
elements,

The OBJECT element is almost useless due to horrendously buggy
implementations. When used for image maps, it makes things much worse.

Yeah, but I'm trying to make some balance - what would currently
work with how it is meant to be done. For me there should be no IMG,
APPLET or IFRAME elements.

I'm confused about what is right and what approach I should take.

First design the page without any image maps. Then consider adding an image
map as an alternative. The choice should be based on a simple question: will
this help users? For example, if it's a matter of selecting a US state in
order to get info about a company's activities in that state, then a map
which is an image map (with states with no activities greyed out somehow)
would probably make things somewhat easier to many users, since they could
see the situation easily and make a choice fast, as compared with selecting
a name from a list of links. But you should still have that list somewhere.

I need the pictures and I need the parts linked to the corresponding
sections. May be after all I'll use IMG, MAP and A elements but here
have come my second and probably more important issue:

Should AREA and A elements specified in a MAP be unified by UAs
which render the map graphically (see my original post for comments
on that)?

--
Stanimir

[Jukka K. Korpela]

Stanimir Stamenkov <s7****@netscape.net> wrote:

Actually this would be a part of a device documentation where there
are two sections (using this technique): Front and Rear View, each
starting with a front/rear view picture/scheme to be used as visual
TOC with links pointing to sections describing the corresponding
parts. Does it make sense to use image maps?

Certainly.

Even then, a redundant list of links should be added, i.e. the image
map should only be provided as an _alternative_.

That's why I'm trying a MAP with A elements.

I'm afraid it's not a practical solution - it's more like W3C's idea on how
the problem might be solved. And if all browsers implemented good old image
maps (using just <img>, <map>, and <area> with alt attributes), the
redundant list of links would not be needed. So it's a matter of interim
solutions.

Using a list of links along with the image map is normally not difficult,
though a bit clumsy unless you have suitable tools. It's probably useful to
tell users explicitly about the redundancy ("select a part either by
clicking on the image or by following link in the list, which contains all
the parts in alphabetic order", or something like that). Not all people can
immediately see that the two "menus" have exactly the same items, just in
very different ways.

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html