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 7, 2019 11:10AM

You're right, the combobox role overrides the role of the text input field.
You should be able to find it using "c" in Jaws/NVDA (just like you
would find a <select>). You should also be able to find it with the
arrow keys in browse mode.
If you can't, that's a bug I think.

The combobox role triggers application/forms mode so once inside the
combobox screen reader browse commands / keyboard navigation stop
working and all navigation within the widget is the responsibility of
the widget author.
If you put other widgets inside the combobox you must control
navigation with Javascript.
I agree with Steve that comboboxes are unnecessarily complex and the
functionality can be implemented differently, either with a <select>
or listbox if it's just a drop down function, or a com bination of
live regions and arrow key navigation for inline autocomplete search,
use the value attribute of the search input to indicate currently
selected option from suggestions.

If you are tackling a specific problem I can probably find some
examples of solutions I'd recommend.


On 9/7/19, Steve Green < <EMAIL REMOVED> > wrote:
> If you are referring to the examples at
> https://www.w3.org/TR/wai-aria-practices-1.1/#combobox, my advice is not to
> use any of them. They might be compliant in theory, but they give a truly
> horrible and incomprehensible user experience. Using JAWS 2019, the
> behaviour is different in each browser, but it's bad in all of them. It
> would take hours to describe all the issues, so I suggest people just try it
> for themselves.
>
> Part of the problem is that the design patterns are trying to be too clever.
> They all include autocomplete, but most authors don't want that - they just
> want to replicate the exact behaviour of a native combobox. None of the
> design patterns does this, and there is no point adding extra features such
> as autocomplete or grid popups until they do. Is this too much to ask for?
>
> Steve Green
> Managing Director
> Test Partners Ltd
>
>
> -----Original Message-----
> From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of glen
> walker
> Sent: 07 September 2019 00:59
> To: WebAIM Discussion List < <EMAIL REMOVED> >
> Subject: [WebAIM] Does role="combobox" eat the identity of nested elements?
>
> If I have a simple pattern of a <div role="combobox"> and it contains a
> nested <input> (as taken from the ARIA 1.1 combobox design pattern [which is
> different from the ARIA 1.0 design pattern]), the nested <input> can be
> navigated to with the tab key but you cannot navigate to it with the E
> shortcut key.
>
> The shortcut key not working happens in NVDA. I'm not sure about JAWS.
>
> If I walk the DOM using the down arrow, it skips over the nested elements of
> the combo. I can't find the <input> using the down arrow. The only way to
> navigate to the <input> is with tab.
>
> Is this expected behavior with the combobox pattern?
>
> For fun I put a <button> in the <div>. I can't navigate to the button with
> the B shortcut key or the down arrow key. I can still tab to the button,
> although when my focus is on the button and I use the B shortcut key to go
> to the next button on the page (a button that is not contained in a combo),
> the B shortcut key is ignored. Nothing happens.
>
> I tried using aria-owns and aria-activedescendent but that didn't seem to
> help.
>
> <div role="combobox">
> <label for="a1">alpha</label>
> <input id="a1">
> <button id="b1">foo</button>
> </div>
> > > http://webaim.org/discussion/archives
> > > > > >


--
Work hard. Have fun. Make history.