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

Re: simple & understandable

From: Anne Pemberton <apembert@crosslink.net>
Date: Thu, 24 Jun 1999 17:41:38 -0400
Message-Id: <>
To: w3c-wai-ig@w3.org

Thanks for your thoughtful comments. 

>What do you see as the problems caused by seven graphics that are
>avoided by a single image?  

It is just one step to get past it to the content for those using readers,
rather than seven steps.

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).

Not all the benefits apply in this situation, as I've detailed below:

>Some reasons include:
>* Better "packaging" of the content in scalable chunks
>  [Important for nonstandard screen displays such as palmsize PCs]

This could be an important consideration.

>* 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]

Access on the image map isn't necessary for all users. The links are
presented on the rest of the page loaded with glorious text. 

>* 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]

Well, I'm the cat who does the maintenance on the web site, and it's as
easy for me to add or change an icon on the image map as to do so with a
single image on the page. In fact, I've been swapping icons on three
different versions of the page yesteday and today, getting opinions on
which graphics to use for what.

>* Imagemaps _lack contextual clues of link status_ because they
>  _do not display borders around hotspots_.  

Do you mean that there should be a border around each graphic? That's easy
to do ... I hadn't done it because it would make the graphics look heavier
on the page.

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
>   users]

I still have much to learn about style sheets, so I'm not clear what
advantage they have.

>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 I take out the lines, the design changes, and the icons are not coming
from the open hand. Nevertheless, taking out the lines would break up the
image map into the separate images. I can put a link on the logo, to return
to the home page (it's not used that way in the site now, but I've already
considered adding it because some people may interpret it that way anyway).
Another layout I tried put the logo in the middle with the graphic links
around it ... 

>* 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.

I'm using Publisher 98, with a final finish in Front Page to alt tag the
large image. I can tag the smaller images in Publisher, but I can't tag an
image map, perhaps haven't discovered how yet...

>* 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.

It's not Front Page ... the extraneous code is done when Publisher converts
it to html (Publisher doesn't let you edit the html like Front Page does).
When I understand what the code does, and know I don't want it, I'll take
it out. How much loading time is saved? in seconds? milliseconds? 

>* 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.

I'd thought of doing that, but not sure if it was helpful and/or would be
another stumbling block for non-graphical users. I do have the picture by
the text on another page on the site: http://www.enabling.org/staff.html
... but wanted to try this one with a simpler graphics & word content for
the opening screen. 

>There's my 2 cents worth.

Thanks for taking the time to study the page and make suggestions.

Anne L. Pemberton
Enabling Support Foundation
Received on Thursday, 24 June 1999 19:42:29 UTC

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