Configuration Checkpoints for Guideline 9

Aloha, all!

During the course of the 28 July 1999 UA teleconference, I
stated that GL9 needed a configuration checkpoint, so as to
endow the user with the ability to choose what information
about each link is presented to the user.

The example I used during the teleconference related
specifically to information about hyperlinks. When moving
through a document by sequentially navigating from link to
link, I expressed the desire to have control over what
information about the link is being presented to me by my
assistive technology, Thus, as I navigate a document link-by-
link, I should be able to choose to have my screen reader
announce the TITLE defined for the hyperlink (if one is
present) or the actual hyperlink text (i.e. the text which
is contained between the <A HREF .> and the </A> tags).

Likewise, if I am navigating a document via a list of links,
the user agent which I am using to peruse the page should
provide me with the option of listing links either by the
TITLE defined for the hyperlink or by the hyperlink text
itself.

Upon closer review of Guideline 9, however, it became clear
-- at least to me -- that at least 2 configuration
checkpoints are needed: one which allows the user to
configure what information is presented about hyperlinks,
and one which allows the user to configure what information
is presented about the FORM controls present in a document.

Therefore, in fulfillment of this action item,  I propose the 
following two new checkpoints for Guideline 9.  The reference 
for this proposal is the 11 August 1999 draft.

FIRST CONFIGURATION CHECKPOINT:
  Ensure that all view, selection, and focus information
  provided by the user agent is available to the user. 
  Display of this information should be made available 
  according to a user-configurable schedule. [Priority 1]

or, less verbosely stated:

  Allow user to configure what information about links is
  presented. [Priority 1]

TECHNIQUES FOR FIRST CONFIGURATION CHECKPOINT:
  1. Provide the user with media-independent information
  about the status of a link as the link is chosen.  For
  example, do not rely solely on font styles or color
  changes to alert the user whether or not the link has
  previously been followed.  The user should be able to
  pick from amongst a list of alert mechanisms (i.e. color
  changes, sound clips, status line messages, etc.), and
  should not be limited to only one type of alert
  mechanism.
  
     1A. For assistive technologies: Provide the user with
     the option to have the TITLE (if present) or the
     hyperlink text made available to the user when the user
     navigates from link to link.
  
  2. Alert the user if following a link involves the
  payment of a fee.

  3. 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.
  
     3A. Provide the user with orientation information about
     the listed links.  For example, idendify a selected
     link as "Link X of Y", where "Y" is the total number of
     links available in the document.
  
  4. Offer the user a list of links which have been visited
  and a list of links which have not yet been visited, or
  provide a media-independent mechanism to distinguish
  between visited and unvisited links.  Do _not_ rely on
  visual or aural prompts *alone* to signify the difference
  between visited and unvisited links.
  
  5. Offer the user a list of links which are internal
  (i.e., local to document) and those which are external,
  or provide a media-independent mechanism to distinguish
  between external and internal links in a list of links.
  Do _not_ rely on visual or aural prompts *alone* to
  signify the difference between internal and external
  links.

As for the placement of this checkpoint, I propose that it
replace Checkpoints 9.5 and 9.6.  Note that the current
Checkpoint 9.5 has been retained as a Technique for the new,
broader, checkpoint.

SECOND PROPOSED CONFIGURATION CHECKPOINT
  Ensure that all form control information--including all
  LABELs, LEGENDs, TABINDEXes, and ACCESSKEYs--are
  available to the user on demand. [Priority 1]
     NOTE: Refer also to Checkpoint 2.5

or, less verbosely stated:

  Allow the user to view a list of FORM controls. 
  [Priority 1]
     NOTE: Refer also to Checkpoint 2.5

TECHNIQUES FOR SECOND PROPOSED CONFIGURATION CHECKPOINT:
  1. Provide the user with the option to view a list of
  form controls in TABINDEX order.
  
  2. Provide the user with the option to view a list of all
  ACCESSKEY bindings for the form.
  
  3. Provide the user with the option to view a list of
  form controls grouped by LEGEND and LABEL.  This can be
  accomplished by providing a definition list (DL), in
  which the LEGENDs are defined as terms (DT) and the
  dependent LABELs and/or form controls (if LABELs are not
  present) are defined as definition definitions (DD).

     Clarification: as a supplement to the clunky
     parenthetic DL, DT, and DD, I would advocate linking
     the term "definition list" to the Lists portion of the
     HTML4 Rec

As for the placement of the second proposed configuration
checkpoint for GL9, it would, naturally, be included in the
sub-section entitled "Form Control Information".

Gregory
--------------------------------------------------------
He that lives on Hope, dies farting
     -- Benjamin Franklin, Poor Richard's Almanack, 1763
--------------------------------------------------------
Gregory J. Rosmaita <oedipus@hicom.net>
   President, WebMaster, & Minister of Propaganda, 
        VICUG NYC <http://www.hicom.net/~oedipus/vicug/>
--------------------------------------------------------

Received on Tuesday, 17 August 1999 23:49:46 UTC