RE: AERT 12.3 proposal

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 11:04:36 UTC