- From: Al Gilman <asgilman@access.digex.net>
- Date: Thu, 16 Oct 1997 12:18:12 -0400 (EDT)
- To: w3c-wai-ig@w3.org
OPTION Making SELECT structures with lots of OPTIONs comprehensible BACKGROUND: Some HTML documents include forms with very long selection menus. The large number of options on these menus makes them hard to browse when using speech-based browsers or browsers that show a few words at a time in a very large print. A possible solution is to find a way to break up such menus into smaller labelled pieces. This would be done by allowing authors to group options and to add labels to these groups. This can be done in such a way as avoid problems for people using existing browsers. Authors would need to consider both old and new browsers when writing HTML pages. Regular windows based browsers would be able to render option groups in a variety of ways, e.g. horizontal rules between groups, slide-right menus as used by Windows 95, or tabbed dialogs. Everyone wins, including people with disabilities. PROPOSAL: The changes to HTML required for this basically involve adding one new element to be called OPTGROUP which represents a group of options. The WAI-HC list has been discussing two proposals. One approach is to use OPTGROUP as a container for the OPTION elements that define the options in each group. To allow for hierarchically nested option groups, the OPTGROUP elements can be nested. Each option group can be labelled using an attribute called, naturally enough, "label". Authors provide labels for options that make sense when viewed with older browsers. In the absence of the context provided by the option groups, these labels need to spell-out the full meaning of each option. For newer browsers that do show the option groups, this would make the options look rather long winded. To deal with this, the label attribute is also added to the OPTION element. Newer browsers use this attribute, when present, in preference to the element's content when fetching the label for each option. This proposal makes the option group structure immediately apparent in the markup, particularly so if the elements are indented to reflect the level of nesting. Example: <SELECT name="ComOS"> <OPTGROUP label="Comm Servers"> <OPTGROUP label="PortMaster 3"> <OPTION label="3.7.1" value="pm3_3.7.1">PortMaster 3 with OS3.7.1 <OPTION label="3.7" value="pm3_3.7">PortMaster 3 with OS3.7 <OPTION value="pm3_3..5">PortMaster 3 with OS3.5 </OPTGROUP> <OPTGROUP label="PortMaster 2"> <OPTION label="3.7" value="pm2_3.7">PortMaster 2 with OS3.7 <OPTION label="3.5" value="pm2_3.5">PortMaster 2 with OS3.5 </OPTGROUP> </OPTGROUP> </SELECT> Users of old browsers would see: PortMaster 3 with OS3.7.1 PortMaster 3 with OS3.7 PortMaster 3 with OS3.5 PortMaster 2 with OS3.5 PortMaster 2 with OS3.7 While users with new browsers would see: ComServers PortMaster 3 3.7.1 3.7 3.5 Another proposal is to make OPTGROUP an empty element like BR, and to use attributes to markup which OPTGROUP each OPTION belongs. To allow for nested option groups, you can also state which OPTGROUP's a given OPTGROUP belongs. Each OPTGROUP is given a unique name with the ID attribute. The axes attribute for OPTION and OPTGROUP lists a set of ID values that name the groups the element belongs to. The option group label is stated using the label attribute on each OPTGROUP. Example: <SELECT name="ComOS"> <OPTGROUP id="master1" axis="Product Type" label="Comm Servers"> <OPTGROUP id="master2" axis="Product Type" label="Routers"> <OPTGROUP id="group1" axes="master1" axis="Model" label="PortMaster3"> <OPTGROUP id="group2" axes="master1" axis="Model" label="PortMaster2"> <OPTGROUP id="group3" axes="master2" axis="Model" label="IRX"> <OPTION axes="group1" axis="ComOS">3.7.1 <OPTION axes="group1 group2" axis="ComOS">3.7 <OPTION axes="group1 group2" axis="ComOS">3.5 <OPTION axes="group3" axis="ComOS">3.7R <OPTION axes="group3" axis="ComOS">3.5R </SELECT> In any older UA it would simply be: +-----+ |3.7.1| |3.7 | |3.5 | |3.7R | |3.5R | +-----+ A newer UA would be something like: +-------------+ |Comm Servers>| |Routers> | +--------------+ If a user were to them go to 'Comm Servers' it would be: +-------------+ |Comm Servers>+-------------+ |Routers> |PortMaster 3>| +-------------|PortMaster 2>| +-------------+ 'PortMaster 3' would then expand to: +-------------+ |Comm Servers>+-------------+ |Routers> |PortMaster 3>+-----+ +-------------|PortMaster 2>|3.7.1| +-------------|3.7 | |3.5 | +-----+ 'PortMaster 2' would expand to: +-------------+ |Comm Servers>+-------------+ |Routers> |PortMaster 3>| +-------------|PortMaster 2>+---+ +-------------|3.7| |3.5| +---+ Non-graphic UAs could build a hierarchy, as they can with tables: Comm Servers PortMaster 3 3.7.1 3.7 3.5 PortMaster 2 3.7 3.5 Routers IRX 3.7R 3.5R QUESTIONS: Would one or another of the above versions be better for accessibility reasons? Under what conditions? How much is this sort of hierarchy going to help speech, braille, etc. users as compared to search-for-string, go-to-number and other functions that the browser can provide to get around in a flat list? FOLLOW UP: Please discuss this issue by sending email to w3c-wai-ig@w3.org . Include the symbol OPTION in the subject heading of your message, to help other subscribers organize the volume of mail we hope this will generate.
Received on Thursday, 16 October 1997 12:18:35 UTC