RE: SELECT/ OPTION GROUPS with the SIZE attribute (fwd)

I guess I am trying to avoid hierarchy and therefore sub-groups. I want
hierarchy, but the current proposal fails to address many of the issues with
hierarchy. 

I also disagree with the suggested rendering as it only addresses single
select lists (unless I missed something).  I still do not know how to handle
multi-select hierarchical lists, or lists with an undefined size. 

I mentioned the following in a mail that was not CC:ed to the WAI group:

Instead of recommending syntax changes to listboxes, why not add text to
HTML 4.0 with guidelines on how to properly use lists to make them more
accessible. This recommendation can also apply to radio button groups and
check box groups (they are no different than a list box in providing a list
of options to the user).  


-Scott

> -----Original Message-----
> From:	MegaZone [SMTP:megazone@livingston.com]
> Sent:	Monday, October 27, 1997 6:28 PM
> To:	w3c-html-wg@w3.org; w3c-wai-hc@w3.org
> Subject:	Re: SELECT/ OPTION GROUPS with the SIZE attribute (fwd)
> 
> Once upon a time Dan Connolly shaped the electrons to say...
> >Scott Isaacs wrote:
> >> Then why does this proposal define a rendering semantic that looks very
> >> hierarchical to me?
> >Because that is the solution that most appealed to the
> >folks in the WAI HC WG that proposed it, I suppose.
> 
> A point I'd like to make.  I tried to be careful in my wording to use
> 'may' or 'might' and not 'will' or 'should'.  The examples given are
> just examples of possibilities.  Without them we found people had a harder
> time understanding the grouping being done.  
> 
> There are a variety of ways the grouping could be handled - from ignoring
> it and displaying as always, to inserting non-selectable elements as
> labels, to doing a true tabbed index or expanding list.  We've tried to
> avoid telling UAs how to render it.  But we want to provide structure so
> that UAs that DO want to do something special have a standard, valid means
> to do so.
> 
> >>  If there needs to be a very simple grouping
> >> mechanism, support a GROUP attribute (or something similar) on each
> >> OPTION and not use a structural construct
> >Thank you for providing a counterproposal.
> >Dave? Al? Megazone? Comments?
> 
> This seems to be a slightly simplified version of the AXIS/AXES proposal.
> Eliminating the OPTGROUP element.  It is actually something I'd though of
> along the way.
> 
> But I think all of the objections to AXIS/AXES, which eventually caused us
> to withdraw that proposal and go with a container element, would still
> hold.
> It isn't as clear to users what is being grouped.  With a container it
> is obvious how things are grouped.
> 
> And what about subgroups?  How would you run multiple Group elements?
> This
> appears to provide only one level of organization.
> 
> >Strictly speaking, all the rendering information in the
> >HTML spec is hints/suggestions; i.e. SHOULD, not MUST.
> >(I need to verify that, but that's my understanding.)
> 
> That is my understanding also.  And I have tried to word things carefully.
> 
> >So I expect that any solution to the long options list
> >problem will carry a "suggested rendering" but no
> >absolute requirements on user agents other than
> >treating the new syntax as conforming HTML, i.e. not
> >barfing.
> 
> That's been our anticipation.
> 
> -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 Tuesday, 28 October 1997 21:47:16 UTC