RE: Client Side vs. Server Side Image Maps

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)

Received on Friday, 1 February 2002 07:12:37 UTC