Re: AERT 12.3 proposal

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.

>               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.

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 Wednesday, 14 June 2000 10:10:00 UTC