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.

[ericmulder1980]

@Daniel15 That would probably even be an easier fix. Thanx for sharing your thoughts. In my post i was merely trying to point out that implementing ARIA (for now) does not mean it is accessible and ready for usage on applications that need to be WCAG 2.0 compliant.

[meelijane]

Would love to see this working. Screenreaders and keyboard-only users really need access to these fields. I'm not so concerned with IE8 but at least a solution for modern browsers would be acceptable. I quite like the IE8 fallback idea. It looks like there are two good PRs up - I'd love to see either one of them merged in.

[StevenTew]

a big +1 on this please

[Natshah]

+1 (+) We need to have this in Chosen. It's a problem

[Natshah]

aria-label (property)

Defines a string value that labels the current element. Also see aria-labelledby.

The purpose of aria-label is the same as that of aria-labelledby. It provides the user with a recognizable name of the object. The most common accessibility API mapping for a label is the accessible name property.

If the label text is visible on screen, authors SHOULD use aria-labelledby and SHOULD NOT use aria-label. There may be instances where the name of an element cannot be determined programmatically from the content of the element, and there are cases where providing a visible label is not the desired user experience. Most host languages provide an attribute that could be used to name the element (e.g. the title attribute in HTML [HTML]), yet this may present a browser tooltip. In the cases where a visible label or visible tooltip is undesirable, authors MAY set the accessible name of the element using aria-label. User agents give precedence to aria-labelledby over aria-label when computing the accessible name property.

[mgifford]

@Natshah Can you do a pull request with the change?

[stof]

@Natshah actually, can you review https://github.com/harvesthq/chosen/pull/2047 to see whether it implements it the right way ?

[Natshah]

Hi,

I have this fixed for my case at this link https://www.drupal.org/node/2384865

Thanks.

Rewarding :)

[Natshah]

Yes. That what should be as something as in the following code. .

      if (this.is_multiple) {
        this.container.html('<ul class="chosen-choices"><li class="search-field"><input type="text" aria-label="' + this.form_field_jq.parents("label") +'" value="' + this.default_text + '" class="default" autocomplete="off" style="width:25px;" /></li></ul><div class="chosen-drop"><ul class="chosen-results"></ul></div>');
      } else {
        this.container.html('<a class="chosen-single chosen-default" tabindex="-1"><span>' + this.default_text + '</span><div><b></b></div></a><div class="chosen-drop"><div class="chosen-search"><input type="text" aria-label="' + this.form_field_jq.parents("label") +'"  autocomplete="off" /></div><ul class="chosen-results"></ul></div>');
      }

But we can use this code:

        $(".views-exposed-widget").each(function( index, element ) {
           $(this).find('.form-type-select .chosen-container input').attr("aria-label" ,$.trim($(this).find('label').text()));
        });

Thanks.

Rewarding :)

[wcndave]

Any update on this? We recently implemented chosen, and had feedback from users using assisstive technology "Jaws" that they cannot use the select fields at all.

[doodirock]

Seems like an important issue to look into. Has there been any movement on this front?

[wcndave]

Nothing that I know of, unfortunately it's very hard to replicate issues given the massive combinations of assistive technologies with browsers and OSes... Normally as long as you can keyboard navigate + you have correct ARIA implementation it should work in the majority of cases.