E-mail List Archives
Re: Does role="combobox" eat the identity of nested elements?
From: Mohith BP
Date: Sep 13, 2019 3:32AM
- Next message: Bryan Garaventa: "Re: Does role="combobox" eat the identity of nested elements?"
- Previous message: Mohith BP: "Re: JAWS pulled up controls from background page"
- Next message in Thread: Bryan Garaventa: "Re: Does role="combobox" eat the identity of nested elements?"
- Previous message in Thread: Birkir R. Gunnarsson: "Re: Does role="combobox" eat the identity of nested elements?"
- View all messages in this Thread
Hi All,
As pointed by Steve Green, there is no way other than <select> to
build an completely accessible custom combobox as of now.
I learnt it around 2 years ago hard way.
Implementing Button with aria-expanded and aria-haspopup and having
listbox which will be visible after expanding the button is one of the
work around. However, this too will have some issues with all the
patterns and ways of navigation.
Thanks & Regards,
Mohith BP
On 9/11/19, Birkir R. Gunnarsson < <EMAIL REMOVED> > wrote:
> I absolutely agree with you guys on the root of the problem.
> I think, instead of continuously updating ARIA adding more and more
> attributes and roles and complexities, the approach should be to make
> ARIA more concise and stricter from a semantic point of view (you can
> use ARIA to implement terribly inaccessible and unsupported widget
> without breaking a single ARIA validation requirement, which makes
> automated tools powerless)
> Together with a strictre validation should come more collaboration
> with browser and AT vendors to ensure adequate support, with fewer
> ARIA properties it should be more manageable.
> And I 100% agree on HTML5,proper support for the <dialog> element, the
> <datalist> element (I created a decently workin auto complete search
> that works in Firefox and Chrome without a single line of JavaScript)
> and development of a <tablist>/<tab> construct and a <tooltip> element
> (there is a <toast> element being proposed that sort of does the same
> thing) my job would be simplified by 75%.
>
> For the auto complete serch, the construct was something like the
> ollowing (I did this a whil back s my <datalist> implementation may be
> wrong)
>
> <label for="search">Search</label>
> <input type="text" list="options" id="search">
>
> <datalist id="options">
> <option value="apples">Apples</option>
> <option value="pairs">pairs</option>
> </datalist>
>
> If you type A and press arrow own, I think both Firefox and Chrome
> will update the value to "Apples" and NVDA / Jaws announce it.
>
> A bit of JavaScript is needed to alert screen reader users when rsults
> are available and probably a tooltip to infomrthem that the field
> contains auto complete suggestions, but it's really quite as simple as
> that.
> I mean, if things like this were properly supported, it would be so
> easy to do accessibility.
>
>
>
> On 9/11/19, Graham Armfield < <EMAIL REMOVED> > wrote:
>> One ideal solution to all this would be for browsers and AT to support 1)
>> extending existing elements, and 2) to actually get behind the newer
>> HTML5
>> elements. Two examples:
>>
>> 1) Using the native <select> element gives a good accessible experience,
>> but it's a pain to style nicely. It also will not support the <option>
>> elements containing anything but text. This is why developers and
>> designers
>> search for a customized listbox solution.
>>
>> If that restriction were relaxed a bit and other elements could be
>> contained within the <option> elements - eg thumbnail images of flags for
>> a
>> currency converter - then devs and designers could have styled controls
>> with inherent accessibility without having to mess about with javascript
>> and ARIA.
>>
>> 2) HTML5 introduced the <datalist> element that can be used with
>> textboxes.
>> The theory (I believe) is that this can work like a combobox where the
>> user
>> can type a couple of characters and a filtered list of options can be
>> shown.
>>
>> If this element were better supported by browsers and AT then the need
>> for
>> complex accessible ARIA patterns would substantially disappear as the
>> native browser functionality could take care of everything.
>>
>>
>> But I guess chicken and egg sums it up.
>>
>> Regards
>> Graham Armfield
>> Coolfields Consulting
>>
>>
>>
>>
>> <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
>> Virus-free.
>> www.avg.com
>> <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
>> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>> >> >> >> >>
>
>
> --
> Work hard. Have fun. Make history.
> > > > >
- Next message: Bryan Garaventa: "Re: Does role="combobox" eat the identity of nested elements?"
- Previous message: Mohith BP: "Re: JAWS pulled up controls from background page"
- Next message in Thread: Bryan Garaventa: "Re: Does role="combobox" eat the identity of nested elements?"
- Previous message in Thread: Birkir R. Gunnarsson: "Re: Does role="combobox" eat the identity of nested elements?"
- View all messages in this Thread