W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > April to June 1999

Re: simple & understandable

From: Kynn Bartlett <kynn-hwg@idyllmtn.com>
Date: Thu, 24 Jun 1999 12:00:16 -0700
Message-Id: <4.1.19990624114420.0162ff10@mail.idyllmtn.com>
To: Anne Pemberton <apembert@crosslink.net>
Cc: "w3c-wai-ig@w3.org"@w3.org
At 09:50 AM 6/24/1999 , Anne Pemberton wrote:
>I created a graphical presentation of the six major links on a site and put
>them all into one large graphic that fills most of the opening screen. So
>far, the single image seems not to pose the problems that a set of seven or
>so graphics on the page would have caused. 

What do you see as the problems caused by seven graphics that are
avoided by a single image?  I believe there are a number of 
benefits in _avoiding_ imagemaps whenever possible, and this
case here would be an example of a time in which it's avoidable
(and thus preferable to avoid).

Some reasons include:

* Better "packaging" of the content in scalable chunks
  [Important for nonstandard screen displays such as palmsize PCs]
* Access to individual image links are better supported in every
  browser than access to imagemaps
  [Important for non-graphics users of graphical browsers as well
   as users of older versions of lynx]
* Ease of maintenance -- if a new section must be added, it's just
  a case of adding a new graphic rather than requiring a remake
  of an imagemap
  [Important for designer maintenance and design flexibility]
* Imagemaps _lack contextual clues of link status_ because they
  _do not display borders around hotspots_.  Granted, most graphics
  these days are included with BORDER=0, but the use of user
  defined cascading style sheets enable a visual user to turn those
  borders back on if the visual clues are thought to be useful!
  Which they _are_!
  [Important for increasing comprehension of web site design among
   users of graphical browsers, including cognitively disabled

>The new version of my page is at:

>What else would be necessary to make the page at
>http://www.enabling.org/tryout accessible to both text and non-text people???

I would make the following changes:

* Get rid of the imagemap and break it into a row of six images;
  lose the radiating lines (unnecessary for the most part) and
  I'd probably put the hand graphic above, not below, the other
  icons for graphic design reasons.  (As an "identity icon" for
  the page, it should be featured most prominently in the design.
  Also, the use of the hand as a separate icon allows for that
  particular graphic to be used as a link by someone who'd want
  to link to the site, as Jonathan suggests.)

* If you must keep the imagemap, please label it correctly with 
  ALT text on each area.  If your FrontPage does not support this,
  then you may need to change web creation software and/or code
  the imagemap by hand.

* As a side note, FrontPage is including a LOT of very extraneous,
  unnecessary HTML code -- such as tables for positioning -- which
  bloats the size and complexity of what should be a simple page.
  You may want to strip out as much as possible of that chaff, since
  it may be locking your design into a specific screen resolution.
  This has implications for users who have configured their screen
  width and display properties to their _own_ needs -- such as low
  vision users -- and may make the page harder for them to access,
  as well as slower for everyone to load.

* The links in your imagemap are repeated as text header links 
  lower in the page, which is good.  I would place a copy of the
  picture next to each textual link, though, because it will
  increase comprehension for "baseline" users as well as non-
  textual users by associating the graphics above with the fuller
  descriptive text used later in the page, increasing comprehension.

There's my 2 cents worth.

Kynn Bartlett                                    mailto:kynn@hwg.org
President, HTML Writers Guild                    http://www.hwg.org/
AWARE Center Director                          http://aware.hwg.org/
Received on Thursday, 24 June 1999 15:05:29 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 13 October 2015 16:21:04 UTC