W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > October to December 1999

A couple of comments

From: Scott Luebking <phoenixl@netcom.com>
Date: Tue, 30 Nov 1999 12:02:09 -0800 (PST)
Message-Id: <199911302002.MAA15571@netcom.com>
To: w3c-wai-ua@w3.org

Just a few comments.

Check points:

4.10 Allow the user to start, stop, pause, and rewind video.
4.13 Allow the user to start, stop, pause, and rewind audio.

    These two checkpoints should have incremental forward and back up.
    Media players of different types often have a slide bar which
    can be hard for blind users or mobility impaired people to use.
    Buttons for incremental back up and forward are easier to use.
    The incremental back up is especially useful for those situations
    where the sound is momentarily not understandable, e.g.  truck
    passing by, announcement over a speaker phone.

4.14 Allow the user to control synthesized speech playback rate.

    Incremental back up might be useful here also.


    User interface issues
    Another user interface issue is making intelligent decisions
    concerning rendering and layout based not only on structure
    of content, but also on the subject matter / information in the

    + Allow the user to control the timing of changes.

    One useful technique is the ability to stop and start
    flow of changes.  Another is to have an option where the user
    is asked if the user agent should continue just before a change is
3.9 Allow the user to turn on and off author-specified forwards that
    occur after a time delay and without user intervention.

   Similarly, the browser could have an option where the browser asks
   the user if it should continue with the forwards.

3.2 Link techniques

   * When presenting the user with a list of the hyperlinks contained
     in a document, allow the user to choose between "Display links
     using hyperlink text" or "Display links by title (if present)",
     with an option to toggle between the two views.
   If the user has selected to show links by title and a particular
   link has no title, then the hyperlink text should be shown for that
   particular link.

3.3 Table techniques

   A rich set of navigation functions could include:

       jump to specific cell
       up/down 1 or more rows
       left/right 1 or more columns
       bottom row in same column
       right column in same row
       jump to row headers for cell
       jump to column headers for cell
       jump back to cell

   There should be a discussion about navigating through nonuniform
   tables, e.g. tables where the data area contains span cells,
   the number of columns can vary between rows, the number of rows can vary
   between columns.  For example, if you navigate up into a cell
   which spans three columns, which cell above the span cell
   should you go into if you go up another cell?  Or what happens if
   you are in the last cell of a row and the previous row has fewer columns?

   If the user agent is taking a guess at header information, the
   user agent might find two or more possibilities.  Providing the user
   with a mechanism to review the possible choices and make a selection
   could be very useful.
   It would probably be helpful if the user could get table summary
   information which includes:

       how many span cells in data area

       range of number of columns in data area

       range of number of rows in columns in data area

       maximum depth of nested tables in data area

       number of nested tables in data area


   The user should be able to get table summary information
   from inside a cell.  It might be helpful to provide two
   types of table summary information, i.e. a brief summary and a
   more detailed summary.

   A comment about problems when a cell has two or more
   nested tables could be beneficial.

3.4 Frame techniques
   * Provide (possibly nested) lists of links to each frame in the
     frameset. The link text can be the frame title (given by "title"
     or "name" if "title" is not present). Or, if no title or name are
     available, render the title (e.g., the TITLE element in HTML) of
     the document that is loaded into the frame.
   If the document has no TITLE element, having the link text be a
   string containing the number of images, the number of words and
   the URL for the frame document can be helpful.  Providing the number
   of words and the number of images can be helpful in guessing the
   purpose of the frame, e.g.  few images and few words is probably
   a title, more words is probably an index, many words is probably
   text area.
3.5 Form techniques
  When navigating through OPTION's, have some key like the ESC key exit
  the list of OPTION's without making a selection.

  When navigating through form controls, how does a user know about
  reaching the end of a form?  Similarly, how does a user know where one
  form ends and another begins?

  Can a user agent assume that the access technology will tell
  the user which radio button in a group of radio buttons is selected?


I think there should be a strong statement at the beginning of document
about the need to have disabled people in the process of designing
and testing the software.  It probably should say that the guidelines can
help avoid pitfalls, but it is quite possible to follow the guidelines
and still end up with an inaccessible user agent.

A number of blind people have commented to me about disliking
confirmation boxes and warning boxes.  Perhaps, there needs to be
a comment about gratuitous use of these boxes.  For lesser important
warnings, the option of getting a sound instead of a box might be preferable
for some blind users.

Any computer-stored documentation for the agent should have a search feature.
(This probably applies more for user agents in the UNIX environment.)

A summary of the current state of a user agent, including various
setting, which can be displayed on request and then cut and pasted
into an email can be useful for tech support for the user agent
and for the access technology.

Received on Tuesday, 30 November 1999 15:25:39 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:49:25 UTC