Several accessibilty issues in DropdownList

[rgommezz]

We found your Dropdown component perfect for our needs in a large scale project we are building.
However, we have to be compliant with accessibility and came across several accessibility issues, since we are trying to support JAWS screen readers and keyboard navigation, so I believe it would be great to address it so that the component could have a much wider audience, and consequently, be more awesome (as it's already):
-Keyboard navigation works as described, as long as tabIndex="0" it's specified, to make the dropdown focusable when you navigate with the keyboard.
JAWS, however, is not able to read each of the elements contained in the dropdown, as soon as you select one with the keyboard.
Here a list of the initial accessibility violations our tool triggered, and I will try to point out the facts causing them.

Potencial violation, Use header elements where appropriate
-Refering to the div parent
Violation, The WAI-ARIA property aria-expanded is not supported global property on element DIV that does not have a WAI-ARIA role
-This is clearly a listbox role, but we are talking about the parent element, <div>, and the listbox role makes sense to be applied in the <ul role="listbox"> element (3 inner levels), with <li role="option"> its corresponding items, as it's already done. So not sure which role makes sense to be applied to the div parent.
I tried <div role="group" aria-label="this is a dropdown"/> and that solves the violation, keeping only the "header" potencial violation. However, when I select another element in the dropdown, close it, and run the tool again, 3 new violations come into place pointing to the inner elements, specifically:
Violation, ID values must be unique.
-That refers to the <li id=""> elements, whose IDs are all the same, an empty string
Violation, a WAI-ARIA widget must have an accessible name
-<ul> elements and <li> elements have a role specified, listbox and option respectively. However they should also define an accessible name specified with aria-label or aria-labelledby , as long as a role is specified.
Potencial Violation, The ul element with WAI-ARIA role listbox might not be keyboard accessible. See rule help for remediation guidance
-That's a false positive, the dropdown is fully acessible by keyboard
Potencial Violation, Use header elements where appropriate
-The same as the initial one referred to the parent <div>

In terms of JAWS screen readers, and based on the violation a WAI-ARIA widget must have an accessible name, I believe specifying an aria-label attribute in the <li> elements, along with the role, will make JAWS read it, something like dinamically binding that attribute to the <li> text content, i.e. <li id="randomID" role="option aria-label="item1">item1\</li>

[jquense]

Hey there thanks a lot for the thorough account. I am more then happy to address any accessibility issues. I do have a few questions tho.

• the unique ids error strike me as odd since the li elements have no id set on them (where is the empty string coming from?
• can you talk more about the aria-label for the <ul> elements? I assume that JAWS wants some sort of readable option text that isn't the inner html of the <li>?

Thanks again for taking the time to submit this

[rgommezz]

the unique ids error strike me as odd since the li elements have no id set on them (where is the empty string coming from?

• id is used by accessibility for various purposes. According to the information I found from the accessibility tool, the id attribute provides a machine-readable identifier for specific elements of the page. Table headers and form controls use these ids to serve as targets for data cells to indicate their header cells, or for labels to indicate the form control to which they belong. When IDs are not unique, the computer cannot determine the correct target.

According to that, maybe setting a random unique id for each of the li elements would solve the problem and would make JAWS determine the targets and read each li inner text

can you talk more about the aria-label for the <ul> elements? I assume that JAWS wants some sort of readable option text that isn't the inner html of the <li>?

• That's correct, to help users navigate a page, WAI-ARIA widgets must have an accessible name specified with aria-label, aria-labelledby or the widget's inner text.

In this case, in the ul element, we can tell the user that we have a set of options to be selected <ul role="listbox" aria-label="possible options">

What do you think?

Thanks for your quick response and your concern on that.

[jquense]

I definately see why the ids are important, but I don't understand why they are being read as empty strings, my issue is more with why it's saying the id's aren't unique when there is no id, perhaps its expecting one? Just generating id's for the options is actually not super easy because it would break how aria-activedescendent works. I need to see if dynamically changing an id on an element is bad form...

I am taking a look at jqueryui's handling of this since they tend to do a good job on a11y, and it looks like instead of providing an actual label for the ul they just say its labeled-by the wrapping widget, which seems reasonable to me as a solution. I'd like to, where possible, limit adding extra labels, since I need to then expose a way for users to localize them from english if they need too.

[rgommezz]

I have tested again the id behaviour in Mozilla and Chrome. This is what I found:

• In principle, having as initial state the dropdown closed and initialized with some default value, none of the <li> elements have any id assigned.
• As soon as I open the dropdown and check the DOM, the li laying the option previously selected (and focused), get an id whereby <li id="rw_1_option>
• When I close the dropdown again, that element keeps the id attribute with an empty string, whereas the remaining li elements don't have any id set on them.

This is all happening without changing the element in the dropdown, the sequence is initial state --> open dropdown --> close dropdown, and in that moment is when running the tool causes that violation with the id holding an empty string

• Therefore, if I have selected 4 different options since the initial state, and with the dropdown closed, we'll have 4 li elements with ids holding empty strings and consequently not unique values.

[jquense]

@rauliyohmc not sure I understand that one, each dropdown widget will get their own unique rw_x_option, and within a dropdown, only one option can ever have the option id. Not trying to be difficult here, just trying to track it down. Nowhere in the code is the id set to an empty string they are all set to undefined when the id switches. Perhaps react is doing something weird?

[rgommezz]

That may be the case. I have also checked that behaviour in one of the examples that you have in http://jquense.github.io/react-widgets/docs/#/dropdownlist.

I understand that if we have 8 elements in the dropdown and we select the 4th one, when the dropdown is opened, that li would get an id equal to rw_4_option. Then, if I switch to another element, let's say the 2nd one and leave the dropdown opened, that element would get an id equal to rw_2_option.
However, I see that x is not variable according to the position but set to a random fixed number in both your examples and my personalised one.

[jquense]

yes it is fixed per widget instance, but in the your example, if you select the 4th element (it gets rw_1_option) if then move the selection to the 2nd element the 4th element has the id removed and it is added to the second element, So at no time do both elements have the same id.

My current hypothesis is that instead of nulling the attribute out, React is just setting them to empty strings when the Id is removed, because (if i understand you) the issue only occurs when you move selection?

[rgommezz]

Yes, that's correct, only when you move selection.
Agree with your hypothesis.

[jquense]

OK so thanks to this issue I pulled out NVDA for the first time in a while and did a big overhaul of how the active descendant stuff is being handling. It should be a lot more durable now, and I can at least confirm that all the dropdowns read out list options on NVDA in chrome and FF at least.

Just need to check whether i broke anything in the meantime before I can get a release out

[rgommezz]

Awesome! Looking forward to the next release.

[rgommezz]

Do you know approximately when will it take place btw?

[jquense]

couple days ago, sorry :P

Glad to have some feedback