Re: SELECT structures with lots of OPTIONs

to follow up on what Daniel Dardailler said:

> I agree with Megazone (sorry I lost your real name) that his proposal
> is superior as it allows for nesting and sharing of options.
> What I don't really get in Dave's or Al's proposal is if the focus is
> just simplicity so that the browser can implement it more easily, or
> because browser can ignore it altogether ?
> It looks to me that even Dave's proposal of 
> <!ELEMENT optgroup O O (option+)>
> woudl require visual browser to do something.

Here are some considerations that were on my mind.

Nested options is enough of a semantically different widget so that
I think it would be appropriate for the browser interest to be polled
on whether they want to support this function.  

I don't know how critical any change in the handling of SELECT
[that requires changed HTML to support it] is for basic
accessibility of the content; I am operating as if this would
fail to get a "must" rating from the WAI Interest Group.

I wrote one note (it seems to have vanished) pointing out that
what people really use in Lynx is

	tabbing through the clickables -- links and form fields

	move to new place by text-string searching

	navigation among the above by number (plus top/bottom of file)

These have been extended to apply inside SELECT.

None of those functions take any change in the HTML for the SELECT.

If put to a poll among the affected users, the above functions might
rate a higher priority than folding or nesting of SELECT choice 

In other works, I do believe that the fancier widget is pushing
the browsers.  And I am not sure I can swear on a stack of bibles
that this push is necessary.

The slight, very incremental option that I raised was motivated
by several considerations:

	- If browsers choose to do something new because of it,
	it is easy to implement.

	- There may be some legacy browsers where the new page content
	will add value even though the browser has not been modified
	[if the excess text in a SELECT happens to be visible but
	not selectable in this browser].

	- Unless we can demonstrate that the greater functionality
	that Megazone proposes is essential for accessibility,
	we should not be interfering with the normal processes of
	the W3C in coming up with a recommendation.

I am not convinced I know what HTML4 should do in this area.  But
these were some of the thoughts that led me to suggest another
low-impact option.

[What I actually am proposing is that the greatest uncertainty on
this proposal is its criticality from an access perspective, and
that to learn more about this we need to review it with the
Interest Group.]

-- Al

Received on Tuesday, 14 October 1997 08:25:15 UTC