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. And grouped lists have long been a standard navigational system for most UAs.
A possible solution is to find a way to break up such menus into smaller labeled 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.
The changes to HTML required for this basically involve adding one new element to be called OPTGROUP which represents a group of options.
The 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 labeled 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 ComOS 3.7.1
<OPTION label="3.7" value="pm3_3.7">PortMaster 3 with ComOS 3.7
<OPTION value="pm3_3.5">PortMaster 3 with ComOS 3.5
</OPTGROUP>
<OPTGROUP label="PortMaster 2">
<OPTION label="3.7" value="pm2_3.7">PortMaster 2 with ComOS 3.7
<OPTION label="3.5" value="pm2_3.5">PortMaster 2 with ComOS 3.5
</OPTGROUP>
</OPTGROUP>
<OPTGROUP label="Routers">
<OPTGROUP label="IRX">
<OPTION label="3.7R" value="IRX_3.7R">IRX with ComOS 3.7R
<OPTION label="3.5R" value="IRX_3.5R">IRX with ComOS 3.5R
</OPTGROUP>
</OPTGROUP>
</SELECT>
On your UA this renders as:
Users of old browsers might see:
+-----------------------------+
|PortMaster 3 with ComOS 3.7.1|
|PortMaster 3 with ComOS 3.7 |
|PortMaster 3 with ComOS 3.5 |
|PortMaster 2 with ComOS 3.5 |
|PortMaster 2 with ComOS 3.7 |
|IRX with ComOS 3.7R |
|IRX with ComOS 3.5R |
+-----------------------------+
While users with new browsers might see:
+-------------+
|Comm Servers>|
|Routers> |
+--------------+
If a user were to them go to 'Comm Servers' it might 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 |
+-----+
Non-graphic UAs could build a hierarchy, as they can with tables under HTML 4.0:
Comm Servers PortMaster 3 3.7.1 3.7 3.5 PortMaster 2 3.7 3.5 Routers IRX 3.7R 3.5R
The examples included here are based off of the OS pick list for the support form at Livingston Enterprises, the employer of the original proposal author.
A common kludged usage for groups in the real world involves placing bogus <OPTIONS> in a select to act as group delimiters. The problems with this are:
An example of this can be found at: <URL:http://www.baynetworks.com/Products/nav/DA510-2742EC-B-nav.html#docs> if you choose the 'Related Documents' list. An edited version of the HTML source is included here:
<FORM TARGET="_top" ACTION="/cgi-bin/baypage.cgi" > <SELECT NAME=url1 onchange="window.open(this.options[this.selectedIndex].value,'_top')" > <OPTION VALUE="">--> Related Documents <OPTION VALUE=""> <OPTION VALUE="">___Brochures <OPTION VALUE="/Products/nav/BR190-2590EC-A.html">5000 MSX <OPTION VALUE="/Products/nav/BR190-2602EC-A.html">BayStream <OPTION VALUE="/Products/nav/BR510-2260WC-C.html">System 5000 <OPTION VALUE=""> <OPTION VALUE="">___Data Sheets <OPTION VALUE="/Products/nav/DA510-2781WC-A.html">ATMSpeed Switching Modules [many OPTIONSs snipped] <OPTION VALUE="/Products/nav/DA510-2777WC-A.html">TokenSpeed Switching Modules <OPTION VALUE=""> <OPTION VALUE="">___White Papers <OPTION VALUE="/Products/nav/WP508-2745EC-B.html">56K [some OPTIONS snipped] <OPTION VALUE="/Products/nav/WP510-2676EC-A.html">Windows NT <OPTION VALUE="">________________________________________ </SELECT> <INPUT TYPE=SUBMIT VALUE=GO ><BR> </FORM>
You can see how this is displayed on your UA:
As you can see, the group headers are included inline, along with blank OPTIONs to provide spacing. This type of use can be found at many sites, indicating authors have a desire for grouped SELECT lists even without accessibility concerns.
Below are the proposed changes to the HTML 4.0 DTD to provide for the new functionality.
<!ELEMENT SELECT - - (OPTGROUP|OPTION)+ -- option selector --> <!ATTLIST SELECT %attrs; -- %coreattrs, %i18n, %events -- name CDATA #IMPLIED -- field name -- size NUMBER #IMPLIED -- rows visible -- multiple (multiple) #IMPLIED -- default is single selection -- disabled (disabled) #IMPLIED -- control is unavailable in this context -- tabindex NUMBER #IMPLIED -- position in tabbing order -- onfocus %Script; #IMPLIED -- the element got the focus -- onblur %Script; #IMPLIED -- the element lost the focus -- onchange %Script; #IMPLIED -- the element value was changed -- %reserved; -- reserved for possible future use -- > <!ELEMENT OPTGROUP - - (OPTGROUP|OPTION)+ -- grouping for OPTION --> <!ATTLIST OPTGROUP %attrs; -- %coreattrs, %i18n, %events -- disabled (disabled) #IMPLIED -- control is unavailable in this context -- label CDATA #REQUIRED -- for user in hierarchical menus -- > <!ELEMENT OPTION - O (#PCDATA) -- selectable choice --> <!ATTLIST OPTION %attrs; -- %coreattrs, %i18n, %events -- selected (selected) #IMPLIED disabled (disabled) #IMPLIED -- control is unavailable in this context -- value CDATA #IMPLIED -- defaults to element content -- label CDATA #IMPLIED -- for use in hierarchical menus -- >
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.