WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Does role="combobox" eat the identity of nested elements?

for

From: Birkir R. Gunnarsson
Date: Sep 11, 2019 8:25AM

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.