OPTION discussion

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