When focus is given to the dropdownlist, a
screen reader (using NVDA) will announce, “list collapsed submenu”. The problem is the selected value is not read
out, and thus a screen reader user has no idea what the selected value is. Any one of the Kendo dropDownList demos will illustrate
this: simply activate a screen reader
like NVDA and focus on the dropdown element. E.g.: http://dojo.telerik.com/@richm/UyUqO
Is there a way to compel a screen reader to announce a dropDownList’s current value without expanding the list?
The overarching ARIA role for a Kendo dropDownList is “listbox”. In an experiment, I forced the dropDownList’s role to “combobox” instead of “listbox”, and NVDA read out the value as expected. The design pattern Kendo UI follows (a wrapper element around the <ul> element) is similar to what is described by the W3 here: https://www.w3.org/TR/wai-aria-practices/#checkbox, and note the outer element has role=”combobox”, not “listbox”.
Should the Kendo dropDownList have a role of combobox instead of listbox? I understand Kendo differentiates a dropDownList from a comboBox by its editable input (http://www.telerik.com/forums/combobox-vs-dropdownlist-widgets, but the W3C explicitly allows for readonly combobox elements. I am not certain and this and would like to hear Telerik’s thoughts.
Is there a way to compel a screen reader to announce a dropDownList’s current value without expanding the list?
The overarching ARIA role for a Kendo dropDownList is “listbox”. In an experiment, I forced the dropDownList’s role to “combobox” instead of “listbox”, and NVDA read out the value as expected. The design pattern Kendo UI follows (a wrapper element around the <ul> element) is similar to what is described by the W3 here: https://www.w3.org/TR/wai-aria-practices/#checkbox, and note the outer element has role=”combobox”, not “listbox”.
Should the Kendo dropDownList have a role of combobox instead of listbox? I understand Kendo differentiates a dropDownList from a comboBox by its editable input (http://www.telerik.com/forums/combobox-vs-dropdownlist-widgets, but the W3C explicitly allows for readonly combobox elements. I am not certain and this and would like to hear Telerik’s thoughts.
4 Answers, 1 is accepted
0
Hello Rich,
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:
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?
Regards,
Georgi Krustev
Telerik by Progress
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).
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:
- add aria-label attribute to the DropDownList widget - http://dojo.telerik.com/OzOFI
- open the popup on focus - http://dojo.telerik.com/IZEpi
Could you let me know whether any of the given workarounds would work for you?
Regards,
Georgi Krustev
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.
0
Rich
Top achievements
Rank 1
Rank 1
answered on 02 Nov 2016, 10:54 PM
Thank you for the thoughtful reply – I appreciate the
insight into the design decisions.
For some reason, in my code, changing the wrapper to “combobox” reads out the value upon focus. See http://dojo.telerik.com/@richm/UyUqO and screen shot. Arrow keys still don’t provide feedback, but I do get the value. Weird!
The aria-label workaround provided works quite well, thank you. My only hesitation is, since we’re overloading aria-label to hold the actual value, how do I set the “real” label for the dropdown, the string describing the purpose of the widget? If I set the aria-label or title of the underlying, then NVDA readout starts with the *value* and ends with the *label*. See http://dojo.telerik.com/@richm/isoJo, the first dropdownlist reads out, “Selected value: Chai list collapsed subMenu DropDown Title”. The user hears the widget label last, which could be confusing.
Same thing happens with aria-describedby.
The second dropDownList updates title with the dropdown label, and keeps aria-label static. The readout order is now more logical, with the title first and label last. Even so, I’m worried that this non-standard use of ARIA could cause problems with other screen readers and assistive technologies.
Other than experimenting with aria-live, I’m almost out of ideas. The auto-open of the dropdowns is a viable idea, but will have to check with the product owners to see if this UX is acceptable for all users.
Thanks - Rich
For some reason, in my code, changing the wrapper to “combobox” reads out the value upon focus. See http://dojo.telerik.com/@richm/UyUqO and screen shot. Arrow keys still don’t provide feedback, but I do get the value. Weird!
The aria-label workaround provided works quite well, thank you. My only hesitation is, since we’re overloading aria-label to hold the actual value, how do I set the “real” label for the dropdown, the string describing the purpose of the widget? If I set the aria-label or title of the underlying, then NVDA readout starts with the *value* and ends with the *label*. See http://dojo.telerik.com/@richm/isoJo, the first dropdownlist reads out, “Selected value: Chai list collapsed subMenu DropDown Title”. The user hears the widget label last, which could be confusing.
Same thing happens with aria-describedby.
The second dropDownList updates title with the dropdown label, and keeps aria-label static. The readout order is now more logical, with the title first and label last. Even so, I’m worried that this non-standard use of ARIA could cause problems with other screen readers and assistive technologies.
Other than experimenting with aria-live, I’m almost out of ideas. The auto-open of the dropdowns is a viable idea, but will have to check with the product owners to see if this UX is acceptable for all users.
Thanks - Rich
0
Hello Rich,
Indeed, with some readers speaks out the selected text when role is 'combobox' (Safari + VoiceOver in my case). Still this improves a bit the situation, we will produce an incorrectly decorated HTML. Even though I am extremely tempted to use the combobox role, with the drodownlist's rendering it wouldn't be possible.
Thank you very much for sharing the additional thoughts on the subject. To be honest, I forgot about the "title" attribute :). It should be perfectly suitable for holding the selected value detail. Combined with aria-label / aria-labelledby attribute produces a fully accessible component (IMHO):
http://screencast.com/t/r778CyxiH
Here is the test demo:
http://dojo.telerik.com/ePuso
(it is based on your tests for title with aria-label combination)
This approach seems to work fine in [Safari + Voice Over], [Firefox + NVDA]. In [IE 11 + JAWS 18], the reader announces the role and selected text, but ignores `title` and `aria-label` attributes. Nevertheless, I still believe that this approach is the best applicable.
Let me know whether it will be feasible to use such implementation.
Regards,
Georgi Krustev
Telerik by Progress
Indeed, with some readers speaks out the selected text when role is 'combobox' (Safari + VoiceOver in my case). Still this improves a bit the situation, we will produce an incorrectly decorated HTML. Even though I am extremely tempted to use the combobox role, with the drodownlist's rendering it wouldn't be possible.
Thank you very much for sharing the additional thoughts on the subject. To be honest, I forgot about the "title" attribute :). It should be perfectly suitable for holding the selected value detail. Combined with aria-label / aria-labelledby attribute produces a fully accessible component (IMHO):
http://screencast.com/t/r778CyxiH
Here is the test demo:
http://dojo.telerik.com/ePuso
(it is based on your tests for title with aria-label combination)
This approach seems to work fine in [Safari + Voice Over], [Firefox + NVDA]. In [IE 11 + JAWS 18], the reader announces the role and selected text, but ignores `title` and `aria-label` attributes. Nevertheless, I still believe that this approach is the best applicable.
Let me know whether it will be feasible to use such implementation.
Regards,
Georgi Krustev
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.
0
Rich
Top achievements
Rank 1
Rank 1
answered on 09 Nov 2016, 05:23 PM
Hi Georgi,
Just wanted to follow-up. We adapted the solution you outlined earlier, using events to update the title attribute, so thank you for that! I added code to optionally take the title from the aria-label or aria-labelledby attributes on the original <input> element. I am hopeful a future release of Kendo UI will utilize those attributes!
Thanks again - Rich