Re: Visible, simple, accessible sites

I don't understand

>2.2  Don't have back and home buttons on the page
>Again these are confusing, as the behaviour conflicts with that
>of Back and Home buttons on the browser.

The home button on a site takes you back to the home page of that site,
whereas the home button on your browser takes you to the default home page
of the browser which is independent of the site.  So I don't see a conflict.

I agree that the "back" button would be confusing.

Len



At 05:04 PM 9/17/99 GMT, John Nissen wrote:
>Hello Judy and WAI friends,
>
>Here a list of points arising from consideration of web
>usability for elderly people, as part of the Senior Online
>project (part funded by the EU).  I have divided them into
>points about visibility, simplicity and accessibility.
>
>1. Visibility
>
>First of all some points on visibility for sighted people:
>
>1.1  Have largish text but not too large.
>Probably 12 or 14 point is around the optimum size.  If too large,
>there may be too much scrolling for comfort.
>
>1.2  Have sensible contrast
>Avoid very dark backgrounds on which the cursor may disappear,
>and avoid dark text on dark background or light text on a light
>background.  (I have come across sites with purple text on navy
>blue background, where I couldn't read a word.)
>
>1.3  Avoid italics - leave browser to choose emphasis
>Small italic characters do indeed look wobbly!  Also use of explicit
>italics in HTML clashes with browser use of italics to highlight links.  
>
>1.4  Don't have anything blinking
>This is irritating, distracting, and potentially harmful for people
>with a certain type of epilepsy perhaps.  (Does this type continue
>to old age?)
>
>1.5  Don't have important information just off bottom of page.
>I've been caught out myself, when I thought there was a full page
>on the screen, but I need to scroll down to see a vital link at the
>bottom of the page.
>
>1.6  Delimit link text clearly 
>Separate links clearly, and try to keep link text on one line.
>
>
>2. Simplicity
>
>Then there are some points about keeping it simple for the user:
>
>2.1  Don't provide a top button (to take user to top of page)
>This is confusing to the user.  The user has to learn to
>scroll anyway, and it's not hard to get to the top.  If they use
>the button rather than scrolling, then Back takes them to the
>bottom again.  I find that irritating, but I suspect it will be
>a source of confusion for most elderly people.
>
>2.2  Don't have back and home buttons on the page
>Again these are confusing, as the behaviour conflicts with that
>of Back and Home buttons on the browser.
>
>2.3  Have a hierarchy, navigated top-down
>Keep the site hierarchical, and encourage people to enter at top level
>(by premoting the URL for the top level page, by always refering to the
>site by this URL, by using it as link from other sites, etc.).
>Have links only down the hierarchy, except for cross-links where 
>they are natural (e.g. in an index, see 2.4).
>
>2.4  Have a guide to site
>Have a list of contents, site map, site search, and/or index to the site.
>Such a page can help a user considerably in finding things on the site.
>To keep with hierarchy principle, this page should be at or immediately
>below the top level.  The information to which this page refers should
>be at lower levels.  (The May 1999 WAI content guide violates this rule!)
>
>2.5  Avoid next/previous buttons - large pages are OK
>The links from a higher level (e.g. table of contents) may point to 
>different named "anchor" points in single large page at the lower level.  
>Search results should be on single page.  (Most if not all modern browsers 
>can start displaying the initial results while the rest of the page continues
>to be downloaded.)
>
>2.5  Keep to a few consistent heading levels
>Keep to three levels at most (i.e. section, subsection and subsubsection), 
>each with consistent H tag numbering.  If you are tempted to have more,
>have another level in the site hierarchy instead.
>
>
>3.  Accessibility
>
>Then there are aspects relevant when the user has assistive technology
>(AT) such as a special browser or a screen reader used with conventional
>browser:
>
>3.1  Tables.  
>These are OK if the tags can be ignored by AT without changing
>the meaning and essential order of presentation of the information.
>Thus if you have a row of buttons and then a row of labels on those
>buttons, there is a problem.  But if you have a row of cells each
>containing a button and a label, that may be OK.
>
>3.2  Frames.  
>Some AT doesn't support them, or support them well.  But I'm against 
>them anyway.  This is mainly because I believe frames are unnecessary.
>In general I believe that it is best to leave the navigation
>commands to the browser - with Back and Forward, and to structure
>the site in a hierarchical fashion.  The user can be confused in
>a frame if they try using the Back button.  I know this, because I
>have got confused myself!
>
>An exception may be for a "help" frame, where context-sensitive
>help can be given alongside the page where the user is having
>difficulty.  However it is not obvious how AT should deal with
>such a frame.
>
>3.3  Pictures
>These need to have have alt text, or other form of descriptive
>text with them.
>
>3.4  Java for snazzy presentation
>In general it is impossible for AT to support Java applets and
>be able to transform the information, generated by applets for display
>on the screen, into an alternative non-visual medium.  However Alt text 
>can be used to provide the information, as for pictures.
> 
>3.5  Javascripts
>In general it is impossible for AT to support client-side scripts.  
>However if one can ignore them, and still have access to necessary 
>information from plain text, then that's OK.
>
>
>Cheers,
>
>John
>-- 
>Access the word, access the world       Tel/fax +44 181 742 3170/8715
>John Nissen                             Email to jn@tommy.demon.co.uk
>Cloudworld Ltd., Chiswick, London, UK   http://www.tommy.demon.co.uk
>
>
>
-------
Leonard R. Kasday, Ph.D.
Institute on Disabilities/UAP, and
Department of Electrical Engineering
Temple University

Ritter Hall Annex, Room 423, Philadelphia, PA 19122
kasday@acm.org        
(215) 204-2247 (voice)
(800) 750-7428 (TTY)

Received on Friday, 17 September 1999 16:52:48 UTC