Accessibility issues with Chosen

[mgifford]

Just linking back to this discussion about accessibility & Chosen from the Drupal Community.

http://drupal.org/node/1271622#comment-4962028

Lots of nice usability enhancements in Chosen.

[bymerej]

relevant piece from that discussion:

Way too much needs work. Appears like accessibility hasn't been considered at
all in this widget, so a lot of WAI-ARIA and JS work would be needed to *
attempt * to make this conform to WCAG 2.0.

The biggest issue, from a 30 second review with FF6 / JAWS12 is that the
component is represented as a input type=text followed by an unordered list
of all options (243 for countries) that the user needs to navigate past to
even ignore the field.

[marcysutton]

The search text field could use a label, for starters, but that is easy to fix.

A bigger issue is that the generated list items do not have anchors in them...can screen reader users take action if they know what the list items are for?

[dotdreaming]

This is a very nice plug-in! I really like the functionality.
Is there going to be any future development into better accessibility? Adding WAI-ARIA to make it conform to WCAG 2.0???

[dotdreaming]

I have just read this article on thefilamentsgroups's website. The ARIA roles could lend itself to Chosen:
http://filamentgroup.com/lab/jquery_ipod_style_and_flyout_menus/

For example: the Chosen results UL would have role="menu" aria-activedescendant="active-menuitem" applied to them and the results <li> would have role="menuitem".
The search box in the Chosen drop down would probably need some sort of ARIA role too??

[marklagendijk]

@dotdreaming you point to the right documentation, but the roles you mention are not quite correct.

I think the following roles should be used:

• combobox.
• option

I think it would be really cool if someone would really dive into the WAI-ARIA documentation and apply it to chosen.

If I can find the time I may do this myself. It doesn't look like it would be very hard to do.

[mgifford]

Any movement on getting ARIA into this project?

Even if it does work with Assistive Technology, it also needs to be tested to see that it also works with keyboard only users.

[mgifford]

Btw, this is just a way to check out the low hanging fruit for accessibility improvements, but WAVE identified some pretty basic things that should be cleaned up -> http://wave.webaim.org/report?url=http%3A%2F%2Fharvesthq.github.com%2Fchosen%2F&js=2

[trickydisco78]

Any of these accessibility issues been address? I've really like to use this on our main university site but these accessibility issues put me off

[Daniel15]

+1 - We've received feedback from a blind user that Chosen dropdown lists are hard to use and they're having difficulties selecting options. They are using JAWS 14 as their screenreader.

[uottawa-wcms]

Tried out just using a keyboard only for navigation. Selecting items works very well and intuitively (down to open the list for a new item, up/down to navigate the list, esc to close the list, enter to select). Removing items from the multiselect was straightforward (backspace) however clearing a single-select dropdown presented itself with more challenges. It looks like, having selected an item, I can press down to open the list again and then navigate up until no option is selected (much like a normal dropdown works if your first item is blank as the examples are), but I'm unable to press Enter to select the null option. Some method for deselecting an option completely (or at least a blank default option) would be very useful.

Also not sure if this is worthwhile, but I noticed that the data is still stored in the hidden select control (I assume this is how it's passed into the form). It might be worthwhile to update the Chosen dropdown when the select is is changed as well - I was debating if this would satisfy criteria 4.1.2 from WCAG, since UAs can interact with the select control programmatically and we could treat Chosen as a facade on top of it for the purposes of accessibility.

[stof]

for the second part, we are requiring to trigger a listz:updated even when you change the value of the select control programmatically to update chosen.
This is required because browsers don't trigger an event when the value is changed programmatically to let Chosen know about it (and it they were doing it, we would still have to avoid infinite loops as we are also changing it programmatically)

[fourcolors]

I'm going to look into adding accessiblity today. @marklagendijk I think what you mentioned the best way to go atm. Ill update on my findings.

[acbramley]

This may be helpful, it may not, but we have strict accessibility guidelines to follow and with version 1.0.0 our client's accessibility tester came back with the following comments:

1. the 'select' associated with the 'label' has display: none; and so the
   'label' is effectively orphaned. The 'div class="chosen-container-single"' that takes
   its place as the form control has no programmatic accessible name or label.

2.There's no visible focus on the faux dropdown.

1. There's no visible focus on the link within the faux dropdown.

I am using this in conjunction with the Drupal Chosen module. We also have a blind tester who noted that once he got to the input he was not aware of being able to type, nor the results returned, including "No results found".

[koleary]

@marklagendijk
Any progress on this issue. I am looking at re-introducing the issue to add Chosen to Drupal core and this is the main blocker.

[koleary]

I found a really good example of how this can be done here:
http://cookiecrook.com/test/aria/multiselect/listbox.html
Here's the javascript: http://cookiecrook.com/test/aria/multiselect/js/aria.js

I believe that this maps almost exactly to the basic chosen functionality.It looks pretty simple to implement using the listbox and multiselectable aria properties
http://www.w3.org/TR/wai-aria/roles#listbox
http://www.w3.org/TR/wai-aria/states_and_properties#aria-multiselectable

I would make a patch myself but I'm not so hot at js.

[alademann]

My PR linked above provides a solution via a much simpler approach centered around the principles of progressive enhancement instead of taking the "deep dive" into making a completely accessible widget out of the current Chosen codebase. I welcome any and all feedback.

[ericmulder1980]

Why focus on ARIA when it is still not properly supported by IE8? Unfortunately this 5 year old browser is still in the list of common browser. This means that wile undergoing an accessibility scan an implementation that depends on ARIA will fail.

Why not use a fallback method that simply disables chosen alltogether and provides a user with the original select? This could be achieved by adding a (hidden) link that would use a small piece of javascript code which disables chosen.

Resource concerning IE8 ARIA support : http://www.w3.org/TR/WCAG20-TECHS/wai-aria_notes.html

[Daniel15]

You could just do browser/feature detection and not use Chosen when IE8 is used.

[obert01]

Hello,

I am blind. I have tested @cooperfellows 's work with JAWS. It work perfectly. The selected option is spoken as I arrow through the options.

Any news on merging this in master?

In my daily work, I use MISP (Malware Information Sharing Platform - https://github.com/MISP/MISP), whose developpers have recently decided to use "chosen" for autocomplete combo boxes. It has become a nightmare for me.

Thank you in advance for your help.

[obert01]

After a few tests, I can confirm the compiled version (.zip archive) posted above (on July 1, 2016) works.

However, when I try @cooperfellows 's branch, or when I clone the @cooperfellows 's branch and then merge with harvesthq/master, the menu options are properly spoken by JAWS but the ENTER key does not submit the form.

[cooperfellows]

Hi @obert01, thanks so much for taking a look at this using JAWS, that was a big piece I was missing during my work.

This branch is way out of date from the current harvesthq/master branch, I will likely need to review the changes and adjust my PR in order to get things back to a working state.

I will try to get to this sometime before the end of the month, I'm pretty backed up at work right now.

I would love to get one of the contributors eyes on it again once it is updated, so I will ping @stof (who looked at the initial pull back in 2016) once I've got it updated.

[obert01]

Thanks a lot.

For your information, I can test with all combinations of JAWS and NVDA screen readers, with the following browser : Internet Explorer 11, Google Chrome, Firefox ESR, Firefox Standard, Microsoft Edge.

[obert01]

Any progress on this?

I'm sorry to insist, but my daily work suffers of this lack of accessibility.

Moreover, adding accessibility support would allow Chosen to be used in public sector / administration websites, since regulation in more and more countries is going in this way.

Thank you

[csmuthukuda]

Hi,
We have an application that has used chosen and now we need to support accessibility but going through this what I can see is this has not been merged yet. It will be really helpful if @cooperfellows can finalize this and merge please.

[cooperfellows]

Hi @obert01 and @csmuthukuda,

I've just made updates to get my PR up to speed with the latest version of Chosen, please take a look here:
#2596

You can get a copy of my forked repository and test on your end. I would love some real life feedback.

It passed all of the TravisCI checks, but I don't think they cover any A11Y issues. Let me know what you think.

[csmuthukuda]

Hi @cooperfellows ,
Thanks, a lot for your dedication to keeping this alive. I'll test this and let you know the feedback of this. I really hope the owners will consider merging this to the master. This is a mandatory requirement now.

[cooperfellows]

Thanks @csmuthukuda I would love for it to be merged in....

@pfiller @stof @tjschuck @koenpunt, anything I can do to help get this looked at? It really is a missing piece to an otherwise incredibly awesome system.

[obert01]

Hi @cooperfellows,

I have tested your awesome work with most current web browser and the JAWS and NVDA screen readers. Thank you !

Arrowing through the options with the keyboard works well: speech and braille feedback is perfect, meaning that all ARIA attributes are well defined. However, when I press ENTER to choose an option, nothing happens. I am not experienced enough with JavaScript to determine if the issue comes from Chosen, or if it is present in the application using it.

To reproduce, try choosing an option in a Chosen combobox only using the keyboard: TAB to focus the combobox, arrow keys to browse the list, ENTER to select.

Once again, thank you very much.

[cooperfellows]

Thanks for that information @obert01. I will take a look and see what I can find.

[cooperfellows]

@obert01 Can you try using this JS fiddle to confirm it's working/not working? THis fiddle is loading the compiled jQuery version of my latest commit.

• https://fiddle.jshell.net/cfellows/r5kp1udb/8/show/light/

I am able to navigate that dropdown using my keyboard (Chrome Latest), but I am NOT running a screen reader.

Let me know what you think.

[obert01]

Hi @cooperfellows,

No problem with your JS Fiddle. Thus I suppose the problem is due to the way Chosen is used in MISP (https://www.misp-project.org/).

I will check this with the MISP project team.

Thanks

[cooperfellows]

Thanks @obert01. Please do let me know what you find out. It could point to an incompatibility with a specific set up of Chosen, so if there is a way for me to see how MISP utilizes it, I can try to take a look at their implementation.

Is chosen used somewhere publicly?

[csmuthukuda]

@cooperfellows can you please give me a new build with the latest changes I don't know how to build it.

[woenlee]

@obert01 @cooperfellows I just tried the Fiddle with NVDA, it seems that the keyboard navigation works perfectly (including selecting with ENTER key). However, when I navigate through with up and down arrow keys, the screen reader reads, "________not selected", i.e. "Bermuda not selected". Is this the expected behavior?

[obert01]

I have the same issue as @woenlee. It is not so harmful. But maybe, the way the "selected" attribute is set on the selected item should be checked.

[cooperfellows]

What is the expected behavior when you "enter" and "exit" a list item? When you navigate down onto a new item, should it read out the newly selected item? Does it also announce what is NO longer selected? @obert01 @woenlee

…

On Sun, Aug 25, 2019 at 12:18 PM Olivier BERT ***@***.***> wrote: I have the same issue as @woenlee <https://github.com/woenlee>. It is not so harmful. But maybe, the way the "selected" attribute is set on the selected item should be checked. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#264?email_source=notifications&email_token=ABT3ZTIESGLX6IYW4BF2QCLQGKWDVA5CNFSM4AATGGB2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5CWTYY#issuecomment-524642787>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABT3ZTMH2KUYYE7HNO2UGH3QGKWDVANCNFSM4AATGGBQ> .

-- ~Cooper

[woenlee]

@cooperfellows After running some axe accessibility tests, I seem to have found a bug in your PR, which explains why it was doing that. In line 342 of Abstract-chosen.coffee, the input has 2 roles assigned to it, "combobox" and "listbox".

<input class="chosen-search-input" type="text" autocomplete="off" aria-expanded="false" aria-haspopup="true" role="combobox" aria-autocomplete="list" autocomplete="off" role="listbox" /> </div> <ul class="chosen-results"></ul>

After giving the <ul the role="listbox" attribute, it seemed to fix the problem!

[mlncn]

Paying customers of Harvest here, and testing to be internally accessible ran into this. Accessibility is a must, and we will move off of Harvest if this is not addressed, if a maintainer with Harvest does not at least show some support to this soon.

[thomasnguyen95]

@obert01 Can you try using this JS fiddle to confirm it's working/not working? THis fiddle is loading the compiled jQuery version of my latest commit.

• https://fiddle.jshell.net/cfellows/r5kp1udb/8/show/light/

I am able to navigate that dropdown using my keyboard (Chrome Latest), but I am NOT running a screen reader.

Let me know what you think.

@cooperfellows
I was testing this JS Fiddle with JAWS 2019 and experienced something slightly different when navigating the options with the up and down arrow keys.
On Google Chrome 71.0.3578.98:
JAWS would not read the current highlighted value unless the list did some scroll/rendering. i.e. If the list is showing

<option selected="selected" value="United States">United States</option>
<option value="Afghanistan">Afghanistan</option>
<option value="Albania">Albania</option>
<option value="Algeria">Algeria</option>
<option value="American Samoa">American Samoa</option>
<option value="Andorra">Andorra</option>
<option value="Angola">Angola</option>
<option value="Anguilla">Anguilla</option>
<option value="Antarctica">Antarctica</option>

9 options, JAWS does not read the highlighted option when pressing down until you get to the 10th option at Antigua and Barbuda. The box does a little auto scroll to highlight Antigua and Barbuda and then read the option.

On IE 11.0.9600.19463: Navigating with the arrow keys seems to read the current highlighted option correctly going up and down. Does not require some sort of render.

Would like to know if anyone else has experienced this. @obert01 @woenlee

[obert01]

Hello and thanks for your work.

Unfortunately, this doesn't work properly. It is extremely hard to describe, as the behavior changes in function of the browser or screen reader used.

I think some aria properties are not present or are not updated. Here the general problems I encounter:

• Scrolling issue: when I arrow down and reach the end of the visible list of items, I have to press two times on the down arrow to focus the next item.
• When I press ENTER to select an item, the focus is not released. The expected behavior would be that the screen reader goes back in quick navigation mode and let me read the rest of the web page. Instead, the arrow keys are still controlling my choice in the list.
• The current scripts do not allow to know if proposals are displayed and how many are they. In most accessible select plugins I know, JAWS/NVDA announce how many results match the string entered in the text input.
• Finally, I have the impression JAWS does not understand if the list is collabsed or expanded. Sometimes, after making a choice with ENTER and trying to read the rest of the page, JAWS still reads the latest proposals that have been displayed.

Good points:

• The auto-complete part works well. If I enter "fra", JAWS pronounce "France", and I can press ENTER to select.
• The items are read properly as I arrow in the list.

I unfortunately don't know many things in regards of ARIA, JavaScript and web in general. I suggest you to be sure the maximum of ARIA properties are properly set and updated.

Please find below the demo and code of a JQuery plugin that perfectly interacts with screen readers:
https://a11y.nicolas-hoffmann.net/autocomplete-list/

I am sorry not being able to help more.

Don't hesitate to post new demos of your work. I am happy to test for you.