Re: screen readers, browsers, & the reporting of ALT on & in image maps

 [Please excuse any format problems with this contribution: due to an
 accident I lost my own copy of the mail that went to the list, and am
 reconstructing the quotations from the list's archive]

In Message-Id: <4.1.20000112104509.00a634d0@pop3.concentric.net> you
made, along with much that was not contentious, the following points
that I'd like to comment on:

> you seem to have missed my point -- my suggestion that len use the
> ALT text quote Select A Direction unquote for the image that
> comprises the image map is not only what i would recommend using in
> this instance; it also underscores the importance of the proper
> usage of textual alternatives...

I was in fact agreeing with that choice, and supporting your use of
ALT to provide a functional textual alternative.  If by attempting to
agree with you I "seem to have missed your point", then I can only
apologise *grin*.

> as for the genesis of the suggestion that quote Picture of a
> Compass, used as an image map unquote is concerned, i have worked
> for commercial web developers who were concerned about
> accessibility, and they would never have allowed me to ALT text the
> compass "Select a Direction", as they wanted people (even those who
> couldn't see, didn't have an image viewer, or who were surfing with
> images off) to know about their glorious art work,

But this is the documented purpose of TITLE and LONGDESC (ex: D-link),
so, what you seem to be saying here is that they would have forbidden
you to design your page in accordance with published specifications.  
Surely the whole point of our discussions here is to supply the WWW
community with the appropriate defences against such abuse?

> i question, however, your suggestion that the phrase "Picture of a
> Compass" be used as a hyperlink title

I submit that this is a misunderstanding.  The TITLE attibute on an
IMG tag seems to be logically associated with the IMG itself.  If the
IMG is a hyperlink (or forms part of a hyperlink) then the TITLE
attribute of the hyperlink (the A HREF= tag itself, yes?) seems to be
the logical place to "convey extended information about the link", and
my experiments with the Opera browser showed that it indeed supported
such usage: leaving the TITLE attribute of the IMG to be available for
extended information about the image itself.  If a browser did not
support that, then I would categorise it as a shortcoming in the
browser, rather than anything wrong in principle with the markup.

While I am clearly aware that currently available browser/versions may
very well be suboptimal in their support for this or that concept in
the specification, and that authors will as a result often resort
short-term to suboptimal authoring techniques in order to help the
users of those suboptimal browsers, I would humbly submit that we not
lose contact with the principles represented in the published
interworking specifications.  Otherwise we have a kind of "arms race"
spiralling down to a low point in which authors are dumbing-down their
markup in order to cope with the suboptimal browsers that people are
using, and browser developers are dumbing-down their support in order
to cope with the suboptimal web documents that are out there, and as a
result, little forward progress is achieved.

Now, to come back to the specific point at issue.  Hyperlinks and
server-side (or dual client-side/server-side) imagemaps do not seem to
be a problem for the logic of my presentation: they all have an IMG
whose TITLE attribute appertains to the image, and an A HREF whose
TITLE attibute appertains to the hyperlink.

In the case of a pure client-side map, there is no such A HREF, and
the only place where the TITLE attribute appertaining to the imagmap
could be placed would be the MAP tag itself.  This seems to me to be
logically impeccable, but could prove operationally inconvenient. I'd
be interested to hear how others react to this logic (but please,
let's not get too distracted by what this or that client version might
do with it today: naturally in the short term one would want to
produce documents that are usable in currently-available browsers, but
I'd rather have a solid foundation showing both document authors and
client agent developers the principles that they should be working
towards - vide my comment above about the downward spiral of an arms
race).

best regards

Received on Thursday, 13 January 2000 07:03:22 UTC