What he said...
Particularly the bit about using completely different interface metaphors for
some things, or even combinations (select a continent or rough area, then
narrow the search...)
in the HTML specification, the server-side maps would just get 0,0 as
coordinates, and be expected to do "something useful" (like provide an
alternative interface mechanism). I would argue that doing that would in fact
meet checkpoint 11.4 as a way of dealing with it, but I haven't seen that
done myself.
Cheers
Chaals
On Fri, 1 Feb 2002, Nick Kew wrote:
On Fri, 1 Feb 2002, Jon Hanna wrote:
> > Does anyone know why, it is recommended that you use client-side
> > images maps instead of server-side.
>
> Because the client side maps can give the client information about
> how the purpose of each area (through highlighting the shapes for
> graphical users, the alt text on <area>s for text users, the title
> attribute etc.) This cannot be done with serverside maps obviously,
> as no more information is available than the is given by the image
> itself.
That's not strictly true. You can define a serverside map which
is equivalent to a clientside one, in the sense that the UA can
retrieve it and display the options. Lynx does that. Of course,
it still costs an HTTP transaction.
What the WCAG and other guidelines are rather weaker on is where
an imagemap doesn't have regions, but is for example a lat/long
input to a geographic map - which of course can't be done
clientside without introducing other - more serious - accessibility
issues. My own approach and recommendation is to offer alternative
<input>s of type text in this situation.
--
Charles McCathieNevile http://www.w3.org/People/Charles phone: +61 409 134 136
W3C Web Accessibility Initiative http://www.w3.org/WAI fax: +1 617 258 5999
Location: 21 Mitchell street FOOTSCRAY Vic 3011, Australia
(or W3C INRIA, Route des Lucioles, BP 93, 06902 Sophia Antipolis Cedex, France)