W3C home > Mailing lists > Public > w3c-wai-hc@w3.org > October to December 1997


From: Daniel Dardailler <danield@w3.org>
Date: Thu, 16 Oct 1997 06:36:56 +0200
Message-Id: <199710160436.GAA12262@www47.inria.fr>
To: w3c-wai-hc@w3.org

Dave's message

which summarizes the situation wrt OPTGROUP is almost perfect.

Unless Meg wishes otherwise, I think we can include it as is, just
removing Dave's personal opinion on the matter (which he can state on
the HTML-WG once this is being debated).

Here's my edit: - opinion + examples.


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.


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.


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

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:

      PortMaster 3

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.


<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

In any older UA it would simply be:
|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>+---+

Non-graphic UAs could build a hierarchy, as they can with tables:
Comm Servers
	PortMaster 3
	PortMaster 2


[do we want to say something to the effect of "please comment on the
importance of the functionality and then whether or not you prefer one
solution over the other" ?]

[do we want to point at the more complete proposals including DTD
piece meals ?]


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
Received on Thursday, 16 October 1997 00:37:15 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:35:00 UTC