Re: Added Forms topic to Open Issues List

to follow up on what Jon Gunderson said:

> Based on comments from the list this morning, I have added a new open issue
> for the Issues List for forms.  Please review the issue (especially Scott
> and Al) to see if I have captured the essence of the issue.

Thanks for the quick turnaround.  A few comments follow at the foot.

> We seem to have alot in the guidelines related to forms right now.
> Does what we have seem adequate? 

No.

> or 
> Do we need to add techniques or change some of the current techniques?

There are only a few new ideas.  Mostly it is that there needs to
be clearer treatment in the wording of the guidelines to the role
of a FORM as a hierarchial element.  FORMs are sub-documents with
an important identity or cohesion of their own, and it is
important to deal with that in orientation etc.  Just as with
TABLEs, when one has to deal with a form it is critical to know
what form one is in and the characteristics of that particular
form.

The guidelines and techniques we have now could stand some
consolidation, which will look like changing them.

-- quoting from
                   WAI User Agent Guidelines Issues List
                                      
   Last updated: $Date: 1998/12/08 12:02 EST $

[snip]
  Forms and Form Controls
  
   Status: Open
   
   Priority: 1
   
   Implementation: Direct [??]
   
   Issue raised by: 8 December 1998, [49]Scott Luebking and [50]Al Gilman
   
   Resolved: 
   
    Issues
    
     * Multiple forms in the same document
     * Forms without specific submit buttons and users knowing that the
       are submitting information
		-- and forms with fields after submit button, users
		knowing that there are optional questions following
		short-form submit.
     * Linking control labels with controls
     * Summary information about the number of forms and the types of
       controls in a form
		-- This is mixing apples and oranges
		-- Number of forms is good page orientation stuff
		-- Types of controls belongs in orientation to this
		form, not this page.
     * Structural information about the relationships in a form
		-- Not what this means
		-- What fields/controls go with which form is essential
		-- inter-control dependencies probably can be glossed over.
     * Form controls that are used as a part of scripting
       
    Working Draft Specifications
    
   [51][Technique: 3.6.2] [Priority 1]
          Allow the user to activate form controls in a
          device-independent manner.
          
   [52][Technique: 4.3.1] [Priority 1]
          Allow users to specify that a page be formatted linearly.
          
   [53][Technique: 5.1.2] [Priority 1]
          Provide the user with information about the number of form
          controls in a document.
		-- don't know that controls per document rates Priority 1
          	-- what controls go in _this form_ is more important
		 	--- may be enough to say how many, particlarly
				when that is 1.
   [54][Technique: 5.1.7] [Priority 2]
          Provide a mechanism to indicate visually the presence of an
          "accesskey" attribute defined for a form control.
          
   [55][Technique: 5.4.3] [Priority 1]
          Allow the user to navigate sequentially among form controls.
		-- These techniques need to be consolidated.  
		   I suspect that we need to come up with a neutral
		   term for structural and seqential navigation
		   and then separately talk about what classes of
		   things need to be able to be reachable in this
		   way, from the different ways of moving around in
		   the currently profile of navigable destinations.
		-- hierarchical navigation is also worth considering
		   such as "back to top of form, skip out of current
		   form," etc.
          
   [56][Technique: 5.6.4] [Priority 1]
          Allow the user to search for a form control in the current
          document based on its text content.
          
   [57][Technique: 5.6.5] [Priority 1]
          Allow the user to search for a form control in the current
          document based on its attribute values.
          
   [58][Technique: 6.2.1] [Priority 1]
          Use operating system application programming interfaces (APIs)
          that support accessibility.
          
   [59][Technique: 6.2.2] [Priority 1]
          For information that can be exchanged through an interface
          defined by a W3C specification, user agents should implement
          that specification.
          
   [60][Technique: 6.2.3] [Priority 2]
          Otherwise, if an accessible application programming interface
          (API) is available for the exchange, user agents should
          implement that interface agents should implement that
          specification.
          
   [61][Technique: 6.2.4] [Priority 2]
          Otherwise, standard interfaces defined for the operating system
          should be used.
     _________________________________________________________________

Received on Tuesday, 8 December 1998 15:50:01 UTC