Screen readers do not announce dropDownList's selected value

5 posts, 0 answers
  1. Rich
    Rich avatar
    7 posts
    Member since:
    Sep 2016

    Posted 31 Oct Link to this post

    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.
  2. Georgi Krustev
    Admin
    Georgi Krustev avatar
    3706 posts

    Posted 02 Nov Link to this post

    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:
    • 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?

    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.
     
  3. Kendo UI is VS 2017 Ready
  4. Rich
    Rich avatar
    7 posts
    Member since:
    Sep 2016

    Posted 02 Nov in reply to Georgi Krustev Link to this post

    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
  5. Georgi Krustev
    Admin
    Georgi Krustev avatar
    3706 posts

    Posted 04 Nov Link to this post

    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
     
    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.
     
  6. Rich
    Rich avatar
    7 posts
    Member since:
    Sep 2016

    Posted 09 Nov in reply to Georgi Krustev Link to this post

    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

Back to Top
Kendo UI is VS 2017 Ready