- From: Gregory J. Rosmaita <unagi69@concentric.net>
- Date: Thu, 18 Nov 1999 00:40:00 -0500
- To: User Agent Guidelines Emailing List <w3c-wai-ua@w3.org>
aloha, y'all!
the following would replace the 3 unordered list items that precede the line
quote
Statement of form submission problems from Gregory Rosmaita:
unquote
in the current (5 november) draft version of the UAGL Techniques document
located at (long wrapping URI warning):
http://www.w3.org/TR/1999/WD-WAI-USERAGENT-TECHS-19991105/#form-techniques
one note -- due to time constraints, i did not suggest specific references
which could be hyperlinked from the techniques proposed below, mainly because i
did not have the opportunity to quadruple check each URI, as is my wont, but
also because i did not want to clutter the proposal with extraneous
information... however, i do have a (partial) listing of such references, and
will post them to the list (or simply send them to ian) as required slash
instructed, although, with only a few exceptions, the terms and specifications
which could be referenced are obvious...
gregory.
--- begin proposed techniques
the following would replace the 3 unordered list items that precede the line
quote
Statement of form submission problems from Gregory Rosmaita:
unquote
in the current (5 november) draft version of the UAGL Techniques document
located at (long wrapping URI warning):
http://www.w3.org/TR/1999/WD-WAI-USERAGENT-TECHS-19991105/#form-techniques
one note -- due to time constraints, i did not suggest specific references
which could be hyperlinked from the techniques proposed below, mainly because i
did not have the opportunity to quadruple check each URI, as is my wont, but
also because i did not want to clutter the proposal with extraneous
information... however, i do have a (partial) listing of such references, and
will post them to the list (or simply send them to ian) as required slash
instructed, although, with only a few exceptions, the terms and specifications
which could be referenced are obvious...
gregory.
--- begin proposed techniques
3.5 Form techniques
* For labels explicitly associated with form controls, make available
label information when the user is navigating among the form
controls. This information must be provided in a device independent
manner, and the user should be able to choose from amongst a list of
mechanisms which provide access to the content of the LABEL.
* For semantic information explicitly associated with groupings of form
controls (i.e. groupings of radio buttons or checkboxes contained in
a FIELDSET), make available the information contained in the LEGEND
defined for the FIELDSET to the user. This information must be
provided in a device independent manner, and the user should be able
to choose from amongst a list of mechanisms which provide access
to the content of the LEGEND.
* Provide information about the percentage of form which has already
been filled out as the user moves through the form controls. This
information must be provided in a device independent manner, and
the user should be able to choose from amongst a list of mechanisms
to ascertain what percentage of the form has been completed. The
user should also be able to query the user agent through a simple,
well documented mechanism (such as a keystroke or keystroke
combination) to ascertain the percentage of the form which has
already been completed.
+ Providing the user with a means of ascertaining what
percentage of a form has been completed as he or she
moves through the form (as well as on a query-on-demand
basis) would assist users from prematurely submitting
an incomplete form. This is particularly important for
anyone moving through a form serially (i.e. moving from
form field to form field), as the SUBMIT mechanism is
often interpreted by the end user as signifying the end
of the form. (Refer also to the technique detailing
methods of providing users with orientation information
about individual form controls when a form control
receives focus for a more detailed discussion of this
issue.)
* Provide the user with orientation information about a form.
Users should be able to query the user agent for:
+ the presence of a form -- the user should be able to
query to user agent for the presence of a form within
the document being rendered. Some user agents (such as
Opera and Netscape Navigator) already indirectly
provide such functionality in a non-interactive manner,
through the provision of "form navigation" keyboard
commands. When invoked, these "form navigation"
commands move the user agent's focus to the first
form field contained in the document currently being
rendered (provided, of course, that the document
contains a form. Although the provision of discrete
"form navigation" commands endows an end user with
the ability to quickly move to the first form field
within a document, the end user needs to be explicitly
notified if the document does not contain a form. Such
notification should be conveyed in a device independent
manner, and the user should not be limited to one
means of notification (i.e. display a message on the
status bar and play a sound).
+ the number of forms in a document
+ the dimensions of each form
* Provide the user with orientation information about individual
form controls when a form control receives focus. For example,
the most basic orientation information would be to identify the
form control with focus as "Field X of Y", where "Y" is the
total number of fields contained in the form.
+ This would prevent users accessing the form serially (such
as a blind user using a screen reader or someone using a
voice browser over a phone) from prematurely invoking the
form's SUBMIT mechanism. It is a common practice for forms
(particularly those used to query search engines) to be
laid out visually, so that the SUBMIT and RESET buttons (if
present) immediately follow a text-entry field, despite the
presence of other form controls (such as radio buttons and
checkboxes) within the FORM element. A user accessing such
a form in a serial manner, therefore, is likely to mistake
the SUBMIT button for the end of the form, and activate it,
unaware that it is followed by further form controls which
could--in the example of a search engine query submission
form--prove an invaluable aid in tailoring the content
being submitted via the form. Use of such orientation
information (i.e. "Field X of Y" or the percentage of the
form completed) will also decrease the amount of time needed
to submit the form (a crucial consideration when forms are
being used to facilitate bidding for online auctions) as
well as reduce the frustration of the end user, who--due to
the visually oriented layout of the form--is nonplussed when
the submission of the form repeatedly leads to a "Form
Incomplete--Use your browser's back button to return to the
form" message.
* When a document contains more than one form, form control
orientation information should also include data which will
identify to which form the form control with focus belongs.
Notification could take the form:
Form Z: Field X of Y
where "Z" identifies the form, "X" the form field with focus
and "Y" the total number of form fields contained in "Form Z"
* The provision of more detailed orientation information pertaining
to form is also highly encouraged:
+ When a grouping of radio buttons receives focus, identify the
radio button with focus as "Radio Button X of Y", where "Y"
represents the total number of radio buttons in the grouping.
HTML4 provides for the grouping of radio buttons using the
FIELDSET element, which allows authors to group thematically
related controls and labels. The LEGEND element assigns a caption
to a FIELDSET. If a LEGEND has been defined for the grouping
of radio boxes, use the information contained within the LEGEND
to more precisely identify the number of radio buttons in the
grouping. For example. if the LEGEND element has been used to
identify a FIELDSET of radio buttons, each of which has a LABEL
associated with it, as "Connection Rate", identify the radio
button as it receives focus as "Connection Rate: Radio button X
of Y: 28.8kpbs", where "Y" represents the total number of radio
buttons in the grouping and "28.8kbps" is the information
contained in the LABEL associated with the radio button with
focus.
+ When a grouping of checkboxes receives focus, identify the
checkbox with focus as "Radio Button X of Y", where "Y"
represents the total number of checkboxes in the grouping.
HTML4 provides for the grouping of checkboxes using the
FIELDSET element, which allows authors to group thematically
related controls and labels. The LEGEND element assigns a caption
to a FIELDSET. If a LEGEND has been defined for the grouping
of radio boxes, use the information contained within the LEGEND
to more precisely identify the number of checkboxes in the
grouping. For example. if the LEGEND element has been used to
identify a FIELDSET of checkboxes, each of which has a LABEL
associated with it, as "Hobbies", identify the checkbox as it
receives focus as "Hobbies: Checkbox X of Y: Horticulture",
where "Y" represents the total number of checkboxes contained
in the grouping and "Horticulture" is the information contained
in the LABEL associated with the checkbox with focus.
* Provide information about what is required for each form control. GUI
browsers, for example, could convey such information via context-
sensitive help. Lynx conveys this information by providing information
about the currently selected form control via a status line message:
(Radio Button) Use right-arrow or <return> to toggle
(Checkbox Field) Use right-arrow or <return> to toggle
(Option List) Hit return and use arrow keys and return to select option
(Text Entry Field) Enter Text. Use UP or DOWN arrows or TAB to move off
(Textarea) Enter text. UP/DOWN arrows or TAB to move off (^Ve for editor)
NOTE: The ^Ve (caret-V, e) command, included in the TEXTAREA status
line message, enables the user to invoke an external editor defined
in the local Lynx configuration file (lynx.cfg). For more information,
please refer to the following technique.
* Allow the user to invoke an external editor when a TEXTAREA receives
focus.
A user may wish to use an external editor, rather than enter text
directly in a TEXTAREA for myriad reasons, including:
+ the ability to more efficiently and expeditiously review the
text being input
+ the ability to spell check the text being input
+ the ability to use macros or other special features of the
external editor, including the ability to increase the
contrast between foreground and background colors, access to
a wider range of screen-display fonts, etc.
+ the ability to save a local copy of the text being input
+ the user's familiarity with the external editor will encourage
the user to actually enter text into a TEXTAREA--an exercise
which is often an extremely daunting task, given the
limitations imposed by the physical dimensions of the TEXTAREA.
A user will also find it much easier to review what he or she
has typed when using an external editor.
* Provide information about the order of form controls (e.g., as
specified by "TABINDEX" in HTML). This is important since:
+ most forms are visually oriented, employing changes in font
size and color
+ users who access forms serially need to know they have
supplied all the necessary information before submitting
the form.
* Provide information about required fields. Since authors often use
color changes, font styling, or a graphical symbol alone to express
that a field is required, the user should be able to configure the
user agent so that it alerts him that the field is required for
submission of the form content. Strategies for achieving this
include:
+ Allow the user to view a list of required form fields. Such a
list should be invokable via a simple and well documented
keybinding.
+ Allow the user to define an alert mechanism (such as the playing
of a sound) which will be invoked when a required field receives
focus. The user should be able to pick from amongst a list of
alert mechanisms (i.e. color or font-style changes to the field
label, the playing of a sound clip, a status line message, etc.),
and should not be limited to only one type of alert mechanism.
Do _not_ rely on visual or aural prompts alone to signify a
required form field.
* Allow the user to configure the user agent so that SELECT form fields
which use the "multiple" attribute to allow the end user to select
more than one OPTION can be transformed into a list of checkboxes.
+ Preserve the LABELs set for the OPTGROUP and each individual
OPTION, and re-associate them with the user agent generated
checkboxes. The LABEL defined for the OPTGROUP should be
converted into a LEGEND for the resultant FIELDSET, and each
checkbox should retain the LABEL defined for the corresponding
OPTION.
+ Note: Lynx automatically transforms SELECT form fields which use
the "multiple" attribute to allow the end user to select more than one
OPTION into checkboxes.
* Allow the user to configure the user agent sot that SELECT form fields
can be transformed into a list of radio buttons.
+ Any such transformation should retain the accessibility information
defined for the original form controls.
+ Note: Lynx provides this functionality as a configurable option,
which can be changed on-the-fly while a page is being rendered.
To promote the comprehensibility of the transformed output for
users using screen-readers and refreshable Braille displays,
Lynx places each OPTION that it transforms into a radio button
on a separate line.
--------------------------------------------------------
He that lives on Hope, dies farting
-- Benjamin Franklin, Poor Richard's Almanack, 1763
--------------------------------------------------------
Gregory J. Rosmaita <unagi69@concentric.net>
WebMaster and Minister of Propaganda, VICUG NYC
<http://www.hicom.net/~oedipus/vicug/index.html>
--------------------------------------------------------
Received on Thursday, 18 November 1999 00:33:31 UTC