proposed techniques (6.3)

I took an action item to do this about a century ago and have placed
my proposal below.  I'd appreciate any and all feedback and am willing
to post an updated version upon comment submission.

Some editting will surely be in order.

Thanks to all who have worked on this by leaving notes and answering
questions and thanks to all for your patience.

   W3C 
   
Techniques for User Agent Accessibility Guidelines 1.0

W3C Working Draft 27-August-1999
text version
  
3.6 Context and orientation
  
    3.6.1 Status information
    
   Checkpoints in this section: 10.4 and [##Tnotify-resource-nav].
*dp* I don't understand the second reference above.   
This is done in the same way as document loading or page loading in
that this information is provided on the status bar in a graphical as
well as a non graphical form.  It is important for dependant user
agents to provide a technique where:
1> one can pole the status of this opperation manually or have it
rendered say by speaking automatically.
2> this feature can be configured to:
a> render all the time:
b> none of the time
c> or by manual means such as through a keystroke.
Internet explorer and netscape currently allow you to choose whether
to "view" or not the status bar.  It is also possible to pole the
status of this bar manually when in "view" by use of a key combination
in screen readers to hear the most currently displayed information
spoken or to have it auto announce upon change of the information
displayed.

3.6.2 Element context
    
   Checkpoints in this section: 9.4.
   *dp* The word "describe" in this Checkpoint clearly to me refers to
an action outside of rendering but rendering can be applied here as
well.  Lynx provides a rendering mechanism where by each link and
other element is numbered and at the same time provides information
about the relative position of the section of the document usually
broken up in chunks of 24 data lines which is being viewed.  two
pieces of information provide this orientation.  the number of the
screen being viewed and the percentage of document that it begins at. 
For description, dependant user agents using screen reading technology
could provide a means where by information about the documents
proportions and the position of the viewport in that document could be
poled or automatically spoken as traversed and this would be
configurable by the user.  Information such as how many and of what
elements are in a document as some user agents do, can also be
"described" ie spoken as the document completes loading and it would
be helpful to provide, as some dependant user agents and lynx do, a
reference to when one is at the top and bottom of the document so that
then inference can be made about where you are in a document or table
from those bits of information.  An alternate "view of the document
such as that provided by netscape in document information could be
used to provide information outside the document concerning how many
of what kind of elements are pressent and the size of the document. 
This information should also be manifest visually if desired by a user
for cognative or other reasons.  
    3.6.3 Links
    
     * Address broken link handling so that it doesn't disorient
users.
       For example, leave viewport as is and notify user.
       
   Checkpoints in this section: 9.5 and 9.6.
*dp* Following a fee is treated separately here because of its likely
highly impacktful results.
   This is most likely only going to be an issue after one has filled
in a form with information for transfering money upon submission of
that information such as filling out an order form or signing up for a
payed service.  Providing a mechanism there fore that would allow one
to check this action through a decission after submision that would
allow them to back out might help to ensure that accidental submission
would not occur.  This might also be a configurable option for the
advanced or sure user to disengage in order to decrease the number of
steps to task completion.  A yes/no on submit would be the most
logical way to ensure efficiency combined with a rendered/described
when encountered payment submission action element.  Note: this should
not be mark up dependant but for more on that: see micropayments?

Information about links status and properties can be provided in an
information view such as that provided by netscape about how many and
what types of elements are in a document.  Some things to avoid if at
all possible are attributing all the links on a page that refer to
another part of the page such as name and # pairs as visitted.  a
vissitted icon might be used in addition to color to mark a link as
having been visitted.  an icon desitnating broken links can also be
provided.  dependant user agents can interpret these in the same way
as they interpret other icons.  these however would be supplied by the
user agent and should be well rendered.  the word vissitted can also
be used or broken for instance and those words can be in the color of
the status if desired.  all information provided about a link should
be configurable at least as to whether it should be present or absent
from the current "view" and also providable for each link on demand if
turned off. 
    
3.6.4 Tables
    
   Checkpoints in this section: 9.9 and 9.8.
*dp* Clearly one of today's most difficult tasks for a person using a
screen reader or other liniar interface device is that which involves
the necessity of accessing information of an "at a glance" nature such
as a multi layered table or nested table.  Further complicating this
issue is the unpredictable and often seemingly arbitrary nature in
which this type of informational delivery is made manifest.  Using the
information available in the document and that which can be inferred
from it,  user agents can build lists of useful elements such as
number of tables in a table, headersof tables,  and headers, and the
number of , rows and columns  embodying a table.  This information
should also be available where relevant as the viewport of the user
agent proceeds through the tabular document.  Procesion through the
document should also be allowable by row, column, cell, header and
table. The type and amound of information made available through
viewport tracking should be configurable and available via poling.  
Lynx for example presents a liniar view of a table but this only works
in simple tables.  where more complex structures are designed,
allowing for the reading of a whole column from header downward is
important as is carrying the ability to perceive which header belongs
to which colomn or group of columns if more than one is spanned by
that header.  It is important for whole cells to be made available as
chunks of data in a logical form.  Some intelligence needs to be
applied here in determining what a logical form for a particular cell
might be.  It might be that a header spans several cells so the header
associated with that cell is part of the document chunk for that and
each of the other cells spanned by that header.  Inside the cell,
order is important.  It must be possible to understand what the
relationships of the items in a cell are to each other.
<!-- examples and further notes go here if someone has them.
-->           
    3.6.5 Form controls
    
   Checkpoints in this section: 9.10, 10.6, 9.7.
*dp* The notes below address the concerns here.  In order to deal with
forms, it is necessary to have access to information about the items
in a form and what is required for each item.  It is most important to
have information about an element that has the focus of the view
port.  If enter is to be used to submit the form, it must be clearly
indicated or a function to trap it should be used so that submission
in this fashion can be confirmed.  It is preferable as is indicated in
the notes below that another method which is also confirmable should
be used.  The order of a form is important as well since when using an
approach that proceeds through the elements one at a time such as
tabbing, all the elements need to be encountered that are necessary
for the required filling of a form before submission is
encountered.        tabbing should not yeild:
"radio button" edit" combo box" checkbox" ... "image submit" while
leaving the label out there unaccessed.  instead, yeilding:
"yes button", "no button" "state combo box", "remember my password
checkbox", ... "submit form" is preferable.
<!-- examples and references go here if any one has them and here are
the notes:
* For labels explicitly associated with form controls (e.g., "for"
       attribute on LABEL in HTML), make available label information
when
       the user is navigating among the form controls.
       
   Statement of form submission problems from Gregory Rosmaita:
   
   Point A: As a user, I do not want to be prompted time I submit a
form,
   provided that I submitted the form by activating its submit button.
   If, however, I simply hit the ENTER or the RETURN key from within a
   FORM control (i.e., rather than explicitly activating the SUBMIT
   mechanism), I would like the UA to request confirmation before
   submitting the form content.
   
   Point B: As a user, I do NOT want the form content automatically
   submitted if I inadvertently press the ENTER or RETURN key.
   
   PROBLEM STATEMENT FOR POINT B:
   
     Inadvertently pressing the RETURN or ENTER key is quite a
prevalent
     phenomenon amongst users of every level of expertise - especially
     those who often find it necessary to switch between user agents.
     Lynx, for example, uses the ENTER key within FORMs as a means of
     exposing drop-down (or pop-up, depending upon your point of view)
     SELECT menus. Thus, when one encounters a SELECT menu using Lynx,
     one: exposes the content of the menu by pressing the ENTER key,
and
     then is able to navigate between OPTIONS using the up and down
     arrows or via Lynx's text-search feature. When one finds the
     appropriate OPTION, it is selected by pressing ENTER, which
causes
     the selected item to be displayed in the SELECT menu listbox.
     
   The problems posed by the default "submit on enter" feature of most
   GUI browsers, is not limited to the SELECT menu problem outlined
   above. Lynx (as well as several other text-based browsers) uses the
   ENTER/RETURN key as a means of toggling several FORM controls, such
as
   the selection of checkboxes and radio buttons.
   
   Moreover, I would like to stress that the "Auto-Submit-On- Enter"
   feature is not only quite problematic for one operating in an
   eyes-free environment, but for those unaccustomed to using online
   forms, and for those unfamiliar with a particular user agent's
default
   key- bindings for forms, as well as those (like myself and
countless
   others) who surf the web using a variety of browsers, often
switching
   from browser to browser -- ALT- TAB-ing from Lynx32 to MSIE to
Opera,
   for example -- in order to better comprehend the contents of a page
or
   while attempting to navigate an poorly structured site or a poorly
   marked-up form
   
   Point C: As a speech user, I am constantly frustrated and
misdirected
   by the use of javascript and event handler controlled pseudo-forms,
   wherein the user is presented with a menu (in the form of a listbox
in
   GUI browsers), and is redirected to a different viewport upon
   selection of an OPTION.
   
   PROBLEM STATEMENT FOR POINT C:
   
     The markup behind such pseudo-forms is a mix of javascript (in
     particular the "function switchpage(select)" command) and HTML
FORM
     controls, which utilize HTML4's event handler script attributes
(in
     particular the "onchange" event handler attribute has been
defined.
     An example (gleaned from the document source for one website
     follows:

  <SELECT NAME="condition" onchange="switchpage(this)">

   When such a menu is encountered by a websurfer who is using speech
   synthesis in conjunction with a javascript enabled user agent, his
or
   her instinctual reaction will be to use the UA's navigation
mechanism
   (usually the up and down arrows) to review the available OPTIONs.
   However, each time a new OPTION is displayed, the user is abruptly
   taken to a new viewport. Conversely, if one is using a user agent
that
   does not support javascript (or has javascript support disabled),
then
   the menu is displayed, but since there is no SUBMIT mechanism
   associated with it, there is no mechanism by which one can use the
   menu to quickly switch viewports - the apparent purpose of this
type
   of pseudo-form. And while one can avoid having the viewport
abruptly
   changed when encountering the menu (at least in the Windows
   environment) by using the ALT-LEFT-ARROW keystroke to display the
menu
   in a drop-down list, (a) very few users know this keystroke, and
(b)
   when one encounters a listbox on a page in an aural environment,
one
   usually assumes that he or she is navigating a valid FORM, in which
   there are no unexpected side effects to perusing the contents of a
   SELECT menu using the arrow keys
   
   Note. I have chosen to address the issue of pseudo-forms in this
   context, for, although they straddle the boundary between "Form
   Controls" and Checkpoint 5.8, pseudo-forms rely on FORM elements
for
   activation This issue has been raised in the past, particularly by
   Chris Kreussling.
   
   Techniques:
    1. Allow the user to configure the user agent. Choices should
       include:
          + "Never Allow Automatic Submission of Form Content " or
"Never
            Submit {Do Not Prompt}"
          + "Always Allow Automatic Submission of Form Content" or
            "Always Submit Without Prompting"
          + "Prompt Before Submitting Form Content"
       The default setting should be: "Prompt before submitting form
       content", so as to allow the user to decide whether or not
HTML4
       event handling will occur automatically.
    2. Configuration can be determined by prompting the user the first
       time an event handled or script-driven FORM is encountered.
       Choices should include:
          + "Submit" {optional verbiage: "This Time Only"}
          + "Do Not Submit" {optional verbiage: "This Time Only"}
          + "Always Allow Automatic Submission of Form Content" or
            "Always Submit Without Prompting"
          + "Never Allow Automatic Submission of Form Content " or
"Never
            Submit {Do Not Prompt}"
          + "Always Prompt Before Submitting Form Content"
       If the user chooses "Prompt Before Submitting Form Content",
this
       prompt could be recycled in an abbreviated fashion. The prompt
       should include:
          + "Submit This Time Only"
          + "Do Not Submit"
          + "Always Submit and Do Not Ask/Warn Me Again"
          + "Never Submit and Do Not Ask/Warn Me Again"
       
   Refer also to [WAI-WEBCONTENT], checkpoint 6.3: Content developers
   must ensure that pages are accessible with scripts turned off or in
   browsers that don't support scripts.
-->   
    
3.6.6 Frames
    
   Checkpoints in this section: None?
*dp* A user agent needs to allow for frames to be listed and entered
upon selection.  When in a frame and that frame controls the action
outside it upon selection of elements in the frame, this needs to be
made known or knowable thorough the ua.  return focus to the point in
a fram where it last was when focus is returned to that frame.  Make
available an alternate method for accessing the contents of a frame. 
If for example, the page does not have a list of links in a frame
available outside the frame, list them.  it is important that the user
be provided with the ability to ascertain which of several frames they
are in or are working with so that identification of elelents in that
frame will be more clear.
<!-- references and examples are welcome -->   
    
3.6.7 Scripts
    
   Checkpoints in this section: 10.1, 10.3.
it would be helpful when encountering a script if the behaviour of the
script could be configurably altered such that each action could be
varified through prompting.  It would be as helpful also if certain
script actions could be prevented or allowed on a configurable
basis.   A <what this script will do> box would also be helpful to
have available.
<!-- examples and references are welcome -->

-- 
Hands-On Technolog(eye)s
Touching The Internet:
mailto:poehlman@clark.net
Voice: 301.949.7599
ftp://ftp.clark.net/pub/poehlman
http://poehlman.clark.net
Dynamic Solutions Inc.
Best of service
for your small business
network needs!
http://www.dnsolutions.com

---sig off---

Received on Thursday, 23 September 1999 15:24:16 UTC