Forms: orientation, control, navigation

to follow up on what Scott Luebking said:

> My suggestion is that a browser has the option of rendering
> additional information for each form.  I believe it would be
> extremely helpful if the beginning and end of each form is
> marked.  The beginning part should include a brief analysis of
> the form like number of radio button groups, number of submit
> buttons, etc.  Also, it would be extremely useful if the tab
> key stopped on the beginning and end of each form so that the
> blind user can get a sense of the extent of each form.
> 
> Could you please add this to the list of open suggestions?

Halleluia, Amen!

**Recommendations (guidelines/techniques to consider)

In addition the user should be able to turn off shortcut
submission of forms.  When shortcut submission of forms is turned
off, either the user activates a submit element that exists in
the document and has the focus prior to activation or the user is
requested to confirm form submission before the user agent
commits the form to the submit transaction.

An introductory overview for forms, such as Scott suggests, may 
merit higher priority than, say, the introductory overview for
documents that is presently in the draft guidelines.

It may not be necessary to make the start of the form a navigation
stop, so long as the orientation information is presented on
entry to the form or return to "top of form."  Moving to the top
of form could position the user at the first form field in the
form, under this option.

**Rationale

A form is an action opportunity, like a link.  Therefore it is
critical that the user understand it.  A form is a hierarchical
action opportunity, containing sub-actions within it.  The cues
that are used in GUI mode to communicate the scope, content and
purpose of the form to the user don't transform effectively into
speech.  So explicit steps are needed to communicate this
structure.

The need to spell out the form structure in audio is consistent
with the grain-size theory about what is different in audio
display.  One thing is to say that audio is linear, but the user
has some short-term memory of hearing and so there are chunks of
sound that can be treated as display atoms that the user will
retain without building a conceptual structure to file them in.
But the typical extent of a form goes beyond this.  The
relationships between the parts of a form, and its extent, are
usually created by the author so that the inclusion of fields in
a particular form is obvious or else there are explicit, mnemonic
submit elements so that the transaction of submitting is clearly
identified, even when the exact scope of prior field entries to
be submitted is not clear.

The hypothesis offered here as a rationale for the breakdown of
form orientation in speech is that the visual display associates
the parts of many forms and that the audio display, with its
finer grain structure, fails to associate them adequately.  One
of the common failures does have to do with linearity.  Forms are
visually designed to capitalize on look-ahead that the visual
user gets; often there is contextual information in what follows
the submit button that the user should be aware of, such as an
option to fine-tune the form.  The visual designer is unaware
that this information is critical, just knows that it is there.
And the visual designer fails to anticipate that the audio user
will not have access to this information when presented the
submit opportunity.

Gregory Rosmaita and I redesigned a form once where we put a
default submit very early on the page but first put an internal
link and advisory that there were advanced option available
following the submit.  This design is a little on the
speech-specific side, but it illustrates the dialog principles
that work.  An auto-generated preview on form entry would seem
to provide a comparable cure.

Al

Received on Tuesday, 8 December 1998 10:27:22 UTC