FORM SELECT element accessibility

I sent this to a couple of the other lists a few weeks back, but I was
advised that I might want to bring it over here now.  Sorry if you've seen
this before.

I'm going to be attending InterOp next week, so anything that comes in 
while I'm away I may not get to until my return.  Thanks.

---cut---

Many times I have developed or used pages with very long SELECT lists.
Picking from these lists is annoying to a normal user, but visually
impaired users I've spoken with say they are positively frustrating.
Every user I've spoken with agreed that having a way to group items
into topics/subtopics would make navigation easier and improve
accessibility.
 
For example, the support ticket submission form on Livingston's web
has 33 software revisions listed.  These could be broken down into
five categories - for product lines - and those could be further
grouped into two categories - type of product.  Which would greatly
reduce the maximum number of options a user would need to pick from at
any given time.
 
I had developed an initial proposal when 3.2 appeared but it had some
obvious flaws.  When the latest 4.0 draft appeared I realized that
'axes' and 'axis' could benefit accessibility on SELECT lists as they
do on tables.  And I generated this proposal.
 
I am very interested in feedback to strengthen the design for
increased accessibility.
 
Version 2 - 9/25/97
 
I added 'selected' and 'disabled' to OPTGROUP element.  After some
thought I decided that users might want to disable an entire subgroup,
especially programatically.  There may also be a desire to preselect
one or more subgroups.
 
Version 1 - 9/21/97
 
You know how you can nest lists with most windowing systems?  Like in
NS bookmarks when you can have an arrow on the right which has a
sublist; so that you can have a hierarchical organization for pick
lists.
 
I'd like to see that for SELECT lists in HTML and I think it can be
done so that it will not break current browsers.  I originally
proposed this just after HTML 3.2 came out, but I think I found a more
flexible way to do it after looking at the HTML 4.0 specification.
The original proposal is at the bottom for reference.
 
This new proposal solves the problem of having elements appear
multiple times in a list in older UAs, when you want them to be in
multiple areas in a new UA.  Using the idea of 'id' and 'axes'
borrowed from the new table spec, you can create groupings.
 
Hope I get the SGML right...
 
<!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 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 --
  axes        IDREFS     #IMPLIED  -- list of id's for OPTGROUPs --
  axis        CDATA      #IMPLIED  -- names groups of related options --
  >
 
<!ELEMENT OPTGROUP - 0 EMPTY -- grouping for OPTION -->
<!ATTLIST OPTGROUP
  %attrs;                          -- %coreattrs, %i18n, %events --
  selected  (selected)   #IMPLIED
  disabled  (disabled)   #IMPLIED  -- control is unavailable in this context --
  value       CDATA      #REQUIRED -- text to display --
  axes        IDREFS     #IMPLIED  -- list of id's for OPTGROUPs --
  axis        CDATA      #IMPLIED  -- names groups of related optgroups --
  >
 
 
As an example:
<SELECT name="ComOS">
<OPTGROUP id="master1" axis="Product Type" value="Comm Servers">
<OPTGROUP id="master2" axis="Product Type" value="Routers">
<OPTGROUP id="group1" axes="master1" axis="Model" value="PortMaster 3">
<OPTGROUP id="group2" axes="master1" axis="Model" value="PortMaster 2">
<OPTGROUP id="group3" axes="master2" axis="Model" value="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
 
----ORIGINAL PROPOSAL----
<!ELEMENT SELECT - - (OPTION | NEST)+>
<!ATTLIST SELECT
        name CDATA #REQUIRED
        size NUMBER #IMPLIED
        multiple (multiple) #IMPLIED
        >
 
<!ELEMENT OPTION - O (#PCDATA)*>
<!ATTLIST OPTION
        selected (selected) #IMPLIED
        value  CDATA  #IMPLIED -- defaults to element content --
        >
 
<!ELEMENT NEST - - (OPTION | NEST)+>
<!ATTLIST NEST
        title CDATA #REQUIRED
        >
 
 
This would be used as follows:
 
<SELECT NAME="testlist">
<OPTION>first item
<NEST title="stuff">
<OPTION>another
<OPTION>yet another
<OPTION>still another
<NEST title="layer">
<OPTION>third level
</NEST>
</NEST>
<OPTION>last item
</SELECT>
 
This would be rendered as:
 
+----------+
|first item|
|stuff>    |
|last item |
+----------+
 
If a user were to them go to 'stuff' it would be:
+----------+
|first item|
|stuff> +-------------+
|last i |another      |
+-------|yet another  |
        |still another|
        |layer>       |
        +-------------+
 
Which would then expand to:
+----------+
|first item|
|stuff> +-------------+
|last i |another      |
+-------|yet another  |
        |still another|
        |layer> +-----------+
        +-------|third level|
                +-----------+
 
the values would all be returned under the key 'testlist' as the NEST
title is just for the display.
 
As unknown tags are ignored, older browsers - and perhaps those
without a convenient way of doing nesting (lynx?) would render it as a
straight list:
 
+-------------+
|first item   |
|another      |
|yet another  |
|still another|
|third level  |
|last item    |
+-------------+
----END ORIGINAL PROPOSAL----
 
-MZ
--
Livingston Enterprises - Chair, Department of Interstitial Affairs
Phone: 800-458-9966 510-737-2100 FAX: 510-737-2110 megazone@livingston.com
For support requests: support@livingston.com  <http://www.livingston.com/> 
Snail mail: 4464 Willow Road, Pleasanton, CA 94588

Received on Friday, 3 October 1997 22:58:35 UTC