Thank you for bringing up the discussion and for the given input.
To be honest, we considered using `combobox` role for both Kendo UI ComboBox and DropDownList widgets in the beginning of their development.
What stopped us using the `role="combobox"` in the DropDownList was the requirement to have a "role=textbox" element inside the combobox control
. Due to the specific rendering of the DropDownList widget we couldn't do that, because "role=textbox" should be focusable.
That is why the widget received the "role=listbox" attribute.
We took the time to investigate the suggested change in the WAI-ARIA attributes, but what we find was not so promising:
- Widget with role="combobox" attribute does not announce the selected value (NVDA output).
- Widget with role="combobox" and internal <span role="textbox" aria-autocomplete="listbox"> behaves like in the previous setup (NVDA result).
In both cases, the reader speaks out only the type of the component. The main reason is that the "textbox" control is not focusable
. Unfortunately, we cannot make the internal <span> element that holds the selected text focusable.
If go crazy and try to make the element that holds the selected text a `role="option"` control, then the reader will read the text. The unacceptable side effect is that the reader will notify the user that length of the list is "1 of 1" (NVDA output
Based on the conducted tests, I still believe that "role=listbox" usage is correct in the context of the DropDownList widget. What we could do in order to improve our behavior and allow the reader to read out the selected value is to:
Could you let me know whether any of the given workarounds would work for you?
Telerik by Progress
Build rich, delightful, *native* Angular 2 apps with Kendo UI for Angular 2
. Try it out today
! Kendo UI for Angular 2 (currently in beta) is a jQuery-free toolset, written in TypeScript, designed from the ground up to offer true, native Angular 2 components.