WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: JAWS and disabled combobox options

for

From: Detlev Fischer
Date: Jan 19, 2017 3:31AM


Hi Jonathan,

So you think the general advice for accessible content would be to avoid optgroup altogether (rather than pushing UA or AT makers to better support it)?
I just had a quick look at the problem myself with Firefox and NVDA, going to an the search page of an app that I developed where we use select with optgroup:
https://anpassungsfinder.de/anpass/anpass_search/
It's the second select labeled "Hilfsmittel"

When I open the select with ALT + ARROW DOWN (or space bar), I am able to type keys to jump straight to options despite the presence of optgroup. So it looks there are implementations where selecting options by letter DO work. (Haven't cecked otzhe browasers and screenreaders yet. BTW in the app, ther ARE issues with selecting options, but I believe they are down to the automatic updating of search results and in turn reduced options dispayed in the select - we need to look at that).

Best, Detlev

--
Detlev Fischer
testkreis c/o feld.wald.wiese
Thedestr. 2, 22767 Hamburg

Mobil +49 (0)157 57 57 57 45
Fax +49 (0)40 439 10 68-5

http://www.testkreis.de
Beratung, Tests und Schulungen für barrierefreie Websites

Jonathan Avila schrieb am 18.01.2017 17:40:

>> Looks like the developer should have used optgroup instead of disabled
>> options. The States are groups, but not values themselves.
>
> Except use of optgroup doesn't allow for keyboard navigation using first letter
> of the item in the optgroup. And optgroup isn't well supported by assistive
> technology in my experience.
>
> Jonathan
>
> -----Original Message-----
> From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On Behalf Of
> _mallory
> Sent: Wednesday, January 18, 2017 7:37 AM
> To: WebAIM Discussion List
> Subject: Re: [WebAIM] JAWS and disabled combobox options
>
> Looks like the developer should have used optgroup instead of disabled options.
> The States are groups, but not values themselves.
>
> cheers,
> _mallory
>
> On Thu, Jan 12, 2017 at 08:09:10AM -0600, JP Jamous wrote:
>> Thank you Bryan. That makes more sense to me now.
>>
>> -----Original Message-----
>> From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On
>> Behalf Of Bryan Garaventa
>> Sent: Thursday, January 12, 2017 12:06 AM
>> To: WebAIM Discussion List < <EMAIL REMOVED> >
>> Subject: Re: [WebAIM] JAWS and disabled combobox options
>>
>> No problem, happy to help. :) One note for others, the bookmarklet was simply
>> a personal utility I created to work around some accessibility issues I was
>> encountering, but this should not ever be part of any development strategy for
>> making something like this accessible.
>>
>> To answer a prior question from JP Jamous, the scenario described has only one
>> select element.
>>
>> E.G Example syntax:
>>
>> <select title="Choose a County" >
>> <option >Arizona</option>
>> <optgroup>
>> <option> County Name One </option>
>> <option> County Name Two </option>
>> </optgroup>
>> <option >California</option>
>> <optgroup>
>> <option> County Name One </option>
>> <option> County Name Two </option>
>> </optgroup>
>> </select>
>>
>> You can quickly jump to California by typing "cal".
>>
>> However if you try the following instead, this is impossible.
>>
>>
>> <select title="Choose a County" >
>> <option disabled >Arizona</option>
>> <optgroup>
>> <option> County Name One </option>
>> <option> County Name Two </option>
>> </optgroup>
>> <option disabled >California</option>
>> <optgroup>
>> <option> County Name One </option>
>> <option> County Name Two </option>
>> </optgroup>
>> </select>
>>
>> This is why this practice should never be done.
>>
>> Instead, client side scripting should be used to check the value of such
>> options and prevent submission if the intended value is not selected.
>>
>>
>>
>> Bryan Garaventa
>> Accessibility Fellow
>> SSB BART Group, Inc.
>> <EMAIL REMOVED>
>> 415.624.2709 (o)
>> www.SSBBartGroup.com
> > > http://webaim.org/discussion/archives
> > > > > >