RE: AERT 12.3 proposal

At 11:03 AM 2000-06-16 -0400, Michael Cooper wrote:

>I think the presence of more than one non-hidden form control should trigger 
>a manual eval.

I agree with the direction you are going in, but I suspect that "more than
one" is going a little too far.  If you diddle the author whenever there
are two or more controls, they may be too likely to disable the check and
not get warned when they do need to do something.  

These things are imperfect.  Real systems work with finite errors, of both
kinds.  Some baddies that didn't get flagged as well as soom goodies that
did.  Not that these classes should be equally likely, but you can't afford
to drive the unflagged baddies to zero without blowing yourself out of the
market.

Just my two cents worth.

PS:  I like your idea of having structured access to a radio button group.
That is one control from a logical or output perspective.  OTOH multiple
checkboxes with the same NAME in one FORM should raise a question to the
author.  Not likely what is intended.

Al

>RE nesting OPTIONs with OPTGROUPs - I guess a trigger is gonna be arbitrary,
>but on the theory that people can hold 5 to 7 items in short-term memory,
>greater than 7 seems like a good trigger, though 10 may be closer to where
>it would be likely to be implemented. By the same theory, only 7
>OPTGROUPs... It would be great if HTML permitted OPTGROUP nesting.
>
>My own experience with FIELDSETs is that they're most useful for checkbox
>and radio button groups that all have the same NAME attribute - I'd almost
>go as far as saying we should require them if that condition is found. But
>they're useful for other purposes too so I think the presence of more than
>one non-hidden form control should trigger a manual eval.
>
>Michael
>
>-----Original Message-----
>From: w3c-wai-er-ig-request@w3.org
>[mailto:w3c-wai-er-ig-request@w3.org]On Behalf Of Al Gilman
>Sent: Wednesday, June 14, 2000 4:13 PM
>To: w3c-wai-er-ig@w3.org
>Subject: Re: AERT 12.3 proposal
>
>
>At 10:09 AM 2000-06-14 -0400, Chris Ridpath wrote:
>>Brian,
>>
>>>               Element: SELECT
>>>               Requirement: Should have OPTGROUPs if more than 10 OPTIONs.
>>>
>>In looking at the menu items from a random selection of programs I see that
>>most items are grouped together in small bunches of 4 or 5 items. However
>>there are some menus that have many (> 10) items. Large menus include
>things
>>like 'bookmarks' or 'open windows'. If we assume that OPTGROUPS are like
>>menus then I favor a smaller number, perhaps 7 OPTIONS, as the trigger and
>>let the user decide if they want to have more.
>>
>
>Yes.  On the order of five seems like the optimum; it is not clear just how
>much over five to set the 'warn' threshold.  It can only be a warning
>because there are some long list such as the names of the US states that
>should not be subdivided but just presented as one long list.
>
>>>               Element: FIELDSET
>>>               Requirement: Should have FIELDSETs if more a total of more
>>> than 10 INPUT, TEXTAREA, SELECT or BUTTONs.
>>>
>>Most dialogs group controls into small groups. If FIELDSETS are like dialog
>>controls then I think we should trigger on a smaller number than 10,
>perhaps
>>7.
>>
>
>Somehow I don't see this as parallel at all.  If all fields are required,
>there may be no requirement for subdividing them up into FIELDSETs.
>
>In the OPTGROUP situation you usually are only going to find and act on one
>OPTION.
>
>In the FIELDSET situation, the number of fields that you are going to
>interact with to conduct a successful transaction tends to be many, not
>one.  I don't think that the same order-of-magnitude-count reasoning
>applies to this latter case.
>
>The logic of when and how to group form controls strikes me as much more
>like providing header for paragraphs than like providing OPTGROUPs for
>OPTIONS.
>
>FWIW
>
>Al
>
>
>>The WCAG also mentions logical groups in 'lists' so I suggest:
>>
>>Element: OL or UL
>>Requirement: Should have no more than 7 LIs
>>Suggested Language: List may have too many list items.
>>Suggested Repair: Display the list and allow user to divide it into smaller

>>sublists
>>
>>The WCAG also mentions logical groups in 'tables' but that is handled by
>>Technique 5.2.1 - [Priority 1] Check data tables for multiple levels of row
>>and column headers
>>
>>The WCAG also mentions using headers to 'break up long stretches of text'.
>>But what is a 'long stretch' of text? How much text to a paragraph? How
>many
>>paragraphs to a header? How much text to a page? Yikes - I think this may
>>have to be a manual check.
>>
>>Chris
>>
>>
>>----- Original Message -----
>>From: "Brian Matheny" <bmatheny@mediaone.net>
>>To: <w3c-wai-er-ig@w3.org>
>>Sent: Monday, June 12, 2000 10:44 AM
>>Subject: AERT 12.3 proposal
>>
>>
>>> Summary of comments so far:
>>> Of course, the choice of '10' for a trigger is subject to change, Gregory
>>> feels its too high, Charles thinks it might be ok since, for example,
>>"most
>>> mobile telephone-based devices haev 10 number keys".  From Greg:
>>>
>>> quote if one of our goals is ensuring interoperability, then FIELDSETs
>are
>>> indispensable...  if i were using a mobile device to fill out a form, i
>>> personally would want to be able to turn on "verbose forms mode", where
>>the
>>> LEGENDs are spoken in conjunction with the individual LABELs defined for
>>> individual form controls...  this is how most screen-readers enunciate
>>> dialog boxes and property sheets (read field label if present before
>>> reading control label and announcing the state of the control, for
>example
>>> "checkbox checked" or "radio button not selected"), and how JFW operates
>>in
>>> "Forms Mode" when MSIE 4x or 5x is running... end quote
>>>
>>> My original suggestion:
>>>
>>> Section 12.3 just has "Any suggestions".  How about:
>>>
>>> Technique 12.3.1 [priority 2] Check for OPTGROUP elements within SELECT
>>> elements.
>>>
>>>          Evaluation:
>>>
>>>               Element: SELECT
>>>               Requirement: Should have OPTGROUPs if more than 10 OPTIONs.
>>>
>>>          Suggested message:
>
>>>
>>>               Group long lists of selections into a hierarchy using
>>OPTGROUPs.
>>>
>>>          Suggested repair:
>>>
>>>               Display the list and allow user to select groups.
>>>
>>> -----------------------------------------------------
>>>
>>> Technique 12.3.2 [priority 2] Check for FIELDSET elements if form
>controls
>>> found.
>>>
>>>          Evaluation:
>>>
>>>               Element: FIELDSET
>>>               Requirement: Should have FIELDSETs if more a total of more
>>> than 10 INPUT, TEXTAREA, SELECT or BUTTONs.
>>>
>>>          Suggested message:
>>>
>>>               Group related form controls and label each group.
>>>
>>>          Suggested repair:
>>>
>>>               Display the controls and allow user to select groups.
>>>
>>> -Brian  35,900+ EV miles since 5/97!  Charged by biomass, wind, solar!
>>> http://people.ne.mediaone.net/bmatheny/ws3f.htm
>>>
>>
>

Received on Friday, 16 June 2000 13:12:46 UTC