E-mail List Archives
Thread: optgroup
Number of posts in this thread: 3 (In chronological order)
From: Paul Bohman
Date: Mon, Mar 08 2004 11:51AM
Subject: optgroup
No previous message | Next message →
Can anyone tell me whether any screen reader supports the <optgroup> tag
at all? I have tested with Window Eyes, JAWS, and Home Page Reader, and
none of them seem to read the optgroup correctly, though for some reason
JAWS does read the first optgroup heading--and only the first optgroup
heading--in my test file:
http://www.webaim.org/temp/optgroup-test.htm
I would appreciate it if people with screen readers could either tell me
how to access the optgroup, or else tell me authoritatively that they
don't support it.
--
Paul Ryan Bohman
Web Accessibility Specialist/Project Coordinator
WebAIM (Web Accessibility in Mind)
www.webaim.org
Center for Persons with Disabilities
www.cpd.usu.edu
Utah State University
www.usu.edu
----
To subscribe, unsubscribe, suspend, or view list archives,
visit http://www.webaim.org/discussion/
From: Tim Harshbarger
Date: Mon, Mar 08 2004 12:01PM
Subject: RE: optgroup
← Previous message | Next message →
Paul,
I was only able to do a quick test with the latest version of JAWS. -- I
have to leave for a meeting soon.
JAWS reads the opt group, but evidently only under certain conditions.
It only reads the opt group when the virtual cursor is on and either you
have just moved to the combobox or you press JAWS+up arrow, which reads the
current line or item with the current focus.
It does not appear to read the opt group if I switch to forms mode and then
select another option -- even when I turn on "Forms mode uses virtual
cursor" in the verbosity dialog.
So, it does read the opt group information (even the main course and salad
groups,) but only under certain conditions.
Tim
From: Terence de Giere
Date: Tue, Mar 09 2004 11:45AM
Subject: Re: optgroup
← Previous message | No next message
Paul,
IBM Home Page Reader (HPR) version 3.02 gives your optgroup test page
the following rendering:
When "tabbling" through the SELECT list using the right arrow key, HPR
does not read the OPTGROUP element labels but just the OPTION elements:
Lunch menu:
(Start of select menu with 10 items.)
turkey sandwich[Selected.]
club sandwich[Off.]
BLT[Off.]
Macaroni salad[Off.]
Potato salad[Off.]
Cobb salad[Off.]
Caesar salad[Off.]
Chicken cordon bleu[Off.]
Meatloaf[Off.]
Seafood pasta[Off.]
(End of select menu.)
IBM Home page Reader is really more like an audio browser than a screen
reader even though it is based on Internet Explorer.
The now defunct pwWebSpeak audio browser also did not read the OPTGROUP
labels or display them in low vision mode, and displayed some erratic
code on the right side of the screen in low vision mode when entering
the list, although it did not read out this code.
The Windows port of the Lynx text browser did not display the OPTGROUP
labels
Support for display of OPTGROUP labels in Opera started with version 7,
but when moving through the list with the keyboard using the arrow keys,
they did not display - they display only when the list opens using the
mouse. The same occurs with the Mozilla browsers, from version 1.0 on up
to 1.7, and that should include Netscape 6 and 7. The same for Internet
Explorer. It seems OPTGROUP is only activated with mouse cursor actions.
You might add a submit button to the test form and a dummy web page
address for the action attribute so you can test behavior after exiting
the select element.
It would appear that the SELECT list OPTIONs need to be written for
comprehension that degrades gracefully because OPTGROUP labels are not
accessible in a number of situations with the current and past browsers
and readers. In your example it is clear what all the items are even
without the OPTGROUP labels.
I am presuming when Tim got the label to read, the list was open on the
screen so the text of the OPTGROUP label printed to the screen. Is that
right? It would appear some fundamental support for OPTGROUP in the
browser itself is missing. In the HTML/xhtml specifications, an
unrecognized element should have its content rendered if possible, but
not its attributes. Here the content is the OPTION elements, but the
label is an attribute. There are a number of quirks in browsers where an
element is supported for mouse actions but not keyboard.
Another feature of SELECT lists that might be problematical with some
browsers is the attribute multiple="multiple", allowing selection of
multiple items. There are some obscure keyboard commands in IE and
Netscape 4 for this but I haven't got it to work from the keyboard with
other browsers, but users more familiar with other browsers may know
tricks I don't.
Terence de Giere
= EMAIL ADDRESS REMOVED =
----
To subscribe, unsubscribe, suspend, or view list archives,
visit http://www.webaim.org/discussion/