Seek a better autocomplete replacement for core (jQuery TokenInput / Select2 / Typeahead.js by Twitter)

Took a quick look at the demo page, some serious accessibility issues w/ this widget. The autocomplete we have in 7.x is quite a bit more accessible, and we are considering #675446: Use jQuery UI Autocomplete for 8.x.

So, in order for us to move this to Core:

1. We would need to fix the accessibility problems upstream
2. We would need to show that this is a better solution than what we have now, jQuery UI autocomplete, and any other options that might be suggested.

Lets not postpone this, but rather discuss the problems. Might also be something to take up with the jQuery guys.

Subscribe. Very worthwhile pursuing this, especially the interaction for multi-select is much easier to understand and operate.

Everett: your review of things that would need work would be very welcome.

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.

We should likely open a meta replace autocomplete.js issue, or re-title #675446: Use jQuery UI Autocomplete and come up with a set of requirements for autocomplete in Core (I commented on this quite some time ago in that issue).

Lots of work upstream, but also not work for us to take on here. I posted an issue in their queue - https://github.com/harvesthq/chosen/issues/264

As with the jQuery autocomplete accessibility issues, it's important that we're vocal about them, but it isn't something we can necessarily fix for their community.

No activity on that upstream issue. Is work going on elsewhere? Anyone have ideas on next steps?

Also Chosen has an MIT license: https://github.com/harvesthq/chosen/blob/master/LICENSE.md

Isn't it a standard requirement that the code be GPL'd?

@cosmicdreams

Code in d.o repositories does need to be GPL licensed. Perhaps someone could reach out to the developer to ask if they would be willing to dual license the code. This worked with the HTML5 Shiv, which was originally not available under GPL.

Doesn't working well in Mobile browsers

Tagging.

From discussions at A11ySprint.

Just found Select2 today. This is a Chosen fork.

http://ivaynberg.github.com/select2/

also supported tagging, remote autocomplete

Chosen, and many others, are great, but we want to reuse JavaScript components and interface elements in order to keep load down. jQuery UI has a small framework in which it reuses its CSS and JavaScript widgets in order to reduce the required load. If there are two jQuery UI elements on the screen, a lot of the code is reused and recycled. You can see how much of it can be recycled over at the demos. #675446: Use jQuery UI Autocomplete.

Just checked and Chosen still has accessibility problems that would be a problem for Core.

Hi, I am trying to take over maintenance of chosen module, due it was very inactive.
Actually I am trying to improve it a bit, cleaning issue queue, but a lot of issues are always related to chosen plugin itself. The plugin as well had some inactivity and a lot of pull-requests are not yet handled by them.
I also found the select2 project, and perhaps I will implement a possibility to choose which plugin you want to use, so we could perhaps get more flexibility there.
I am not sure, but it looks like I still not yet have enough access to create new branch, will have to check and write Main-Maintainer of the module again. (I am doing this stuff the first time).
Just commited already some bits and bytes to dev branch.
For now, I also think it will not be ready for use this as D8 basic, lets see what I can do in next weeks. Unfortunately I have to do this work in my free time, which I don't have that much currently.

Cheers!

Does Select2 have same issues with accessibility? It looks much better then Chosen
Suppose some functionality could be incorporated into jQ UI autocomplete

I just wanted to chime in and report that we tried using Chosen on one site a month or so ago, but found that many people had trouble with it on different browsers. Unless you're on a desktop computer running Chrome, FireFox or Safari, Chosen needs a bit of work to really improve usability. Accessibility issues aside, I think Chosen needs to be tested a lot more on mobile phones and tablets. The idea is awesome, the execution just needs improvement if we were to consider using it in Core.

Agreed.

Well, jQuery UI Autocomplete does not really deliver what Chosen delivers. jQuery UI Menu would, but that's still vaporware at this point, there's no sign of progress, and its interface/experience and look & feel is far inferior compared to Chosen to begin with.

I really wonder how hard it can be to (re-)implement the parts of Chosen that we're looking for (a combination of text field + autocomplete + "chosen options") in a modern and accessible way? Or to make Chosen itself accessible?

What ultimately matters most IMHO is the user interface concept of Chosen. It makes autocomplete fields usable, instead of just providing autocomplete functionality. Our autocomplete.js as well as jQuery UI's Autocomplete really look like stone-age 1995 technology compared to that. I think that end-users just simply expect a modern user experience à la Chosen from web sites today.

So I actually started to look into this, performed a "hardcore forking action" ;), created a sandbox branch, patched the library into system_library_info(), hacked form.inc and autocomplete.js, ...

...only to realize that Chosen was designed for a completely different job and doesn't solve a single thing for us. ;)

Reasoning being: It was designed to improve SELECT elements, not INPUT[type=text] elements. And while it looks "autocomplete-ish", it doesn't contain any facility to do so, you need to wrap it with additional user-land libraries à la ajaxChosen for autocomplete-alike functionality, whereas the entire library is still select-element based, and quickly hacking/pseudo-faking it onto a text input field quickly shows that it's not at all prepared for that...

So. So much to Chosen. ;)

What we actually want is this: http://loopj.com/jquery-tokeninput/

A simple text field. Autocomplete. Fancy selected options. Solid API. And other fanciness. And GPL.

Now, how does that sound? :)

jQuery Tokeninput looks very, very sweet. Nice UI, pluggable token sources, only 30k before minification and gzipping.

Oh YAY! It defaults to ?q= to pass the search string the callback URI and that's exactly what we're doing over in #1831324: Form API #autocomplete_path JS and callbacks to use GET q= parameter instead of menu tail :)

Is anyone able to take this on and get done this week?

Would be good if someone updated the Issue Summary and specifically stated how this is better than our current autocomplete. Also does Tokeninput meet accessibility requirements?

@cweagans: I think at least the addition of the new library would be bound to feature freeze.

@moshe: Will try to update the issue summary asap.

Aside from keyboard navigation (which works excellently), accessibility has not been tested yet, but contrary to Chosen, the TokenInput library's actual code is pretty straightforward and technically looks fairly similar to autocomplete.js — it appears to me that we can simply copy over whatever is missing from autocomplete.js into the upstream library, which doesn't sound like a blocker to me.

I did some further research, and found out:

The Select2 fork of Chosen actually supports

1) the same features as jQuery TokenInput,

2) plus all features of Chosen,

3) plus substantial performance improvements with regard to remote data loading,

4) plus support for infinite scrolling (now, how's that for an autocomplete?)

...and unlike the original Chosen library, it's not developed in CoffeeScript and compiled into jQuery, but instead, a simple and small jQuery plugin. It's also actively maintained, and GPL.

As such, it would have some concrete, tangible benefits: One library to rule them all.

Namely, Select2 works as replacement for:

- very large select lists, improving the user experience by allowing the user to filter/search the select dropdown options

- tagging and autocomplete fields, allowing the user to enter options that do not exist in the preexisting options.

- and more...

Wowzers. I like.

Beside features and all a couple of data points.

Size (min+gz)

• Select2: 10kb
• Chosen: 5,9kb
• tokeninput: 3,4kb

Might be worth it, might not be. Also to keep in mind, mobile friendlyness and a11y.

Mobile

• Select2: it's dead slow on mobile (nexus s) as in not acceptable, also the combo thing fails, can't search anything, textbox closes when keyboard shows up.
• Chosen: some zooming issues for me but I can search for stuff and access all the options
• tokeninput: works great and fast.

This is not for/against a specific one, it's just data.

Our use cases are autocomplete and combobox. Need to see which one is more important. Keeping in mind that if we're serious about mobile it'll be hard to justify chosen and impossible to justify Select2 as we can see in their demos.

This was just released today: Typeahead.js by Twitter.

Autocomplete from select, ajax, powerful cacheing, multiple selects on the same page, lookahead suggestions, and more. Not to derail with another choice, but if it's good enough for and used and tested by Twitter, it's probably a good option.

re: #32: I checked Typeahead earlier today and it seems to be a pure "search" facility only; it does not provide any means that would make it suitable for free-tagging autocomplete widgets. Thus, not a candidate for this issue here AFAICS.

Also, it really doesn't look like it is accessible:
https://github.com/twitter/typeahead.js/issues

Then none of the others are particularly either.

This is a D9 issue though now, right?

A demo missing a Label isn't the script itself problem.

furthermore,
jQuery tokeninput, we can theme the result and popup list. Also, I couldn't see any big different between it and CORE autocomplete (accessible).

The big difference between Core's autocomplete (and for that matter jQuery's autocomplete) and any of the javascript libraries above is testing.

I had a productive exchange with a TypeAhead.js developer last night. He might even introduce WAI-ARIA into his project and fix up the demo for testing reasonably soon. But none of these modules have really been tested by popular screen readers to determine if they work in a similar way using assistive technology.

I do think the bigger issue though is if this can be brought into Core in D8 now or not. I think this would have to be a feature enhancement.

Maybe we can get folks behind #675446: Use jQuery UI Autocomplete it is listed as a task at least, so there is a hope it can get into Core in D8. I don't see how we can do it with these other libraries though.

TypeAhead does not look like it was meant to be used multiple times in the same textfield, which is a requirement for autocomplete.

In case this issue becomes very long as all these projects evolve to meet our standards or not (be it for D8 or D9) and so that others don't have to read through this whole issue as it gets longer and longer, lets please update the issue summary to be a feature comparison between the possible candidates.

temporarily tagging. :)

I checked in on most of the projects listed here. Of all the projects I looked at, none, have made any advancements on accessibility since January.

I think this issue is going to have to get pushed off to D9 as these libraries just aren't going to meet the accessibility requirements for Core. I'm going to move this to D9, but feel free to bring it back to D8 if you think that this issue can be addressed in time.

For D8, let's focus our efforts on #675446: Use jQuery UI Autocomplete

drupal module for chosen: http://drupal.org/project/chosen

@TechNikh: If you had read through the issue, you'd have seen that back in #22 the title was "Add Chosen library to core and use wherever possible".

right. I just wanted to put the link to the module for people who were looking for similar functionality in their current drupal 7 site, like I was.

@Bojhan believes in #1337628: Enhance language select form with textbox and other tools that a Chosen one-line select box like solution would be **very** important for the first installer screen, so I'm moving this back to Drupal 8. Is Chosen generally inaccessible or just with some options? Do all the bright people on this issue see a solution for that limited use case? Eg. looking at twitter typeahead.js does not seem to be viable because it does not show the options, it only shows a textfield and you need to guess: http://twitter.github.io/typeahead.js/examples/

Tag monster.

If someone wants to create a patch with one or the other I'd be happy to do some accessibility testing on it. It's also something that folks here should be commenting on upstream:
https://github.com/harvesthq/chosen/issues/264?source=cc
https://github.com/ivaynberg/select2/issues/452
https://github.com/loopj/jquery-tokeninput/issues/478

Or perhaps just generating the pull request and submitting it to them. Either way it would be good if this problem were fixed upstream. Thus far I haven't seen any real interest in fixing accessibility issues by these folks. However, if Drupal were going to choose one, looking at accessibility as one requirement, then maybe they would be more interested.

IE7

I've been seeking a solution for a project I'm working on, and ran across Selectize.js. Thought I'd throw it in this thread for consideration.

http://brianreavis.github.io/selectize.js/

Link to issue asking about accessibility in Selectize:
https://github.com/brianreavis/selectize.js/issues/349

Seems like we need to just choose a library and commit to getting that in core. My vote is with chosen. We should update the issue summary with all the options.

They are all going to need accessibility work from what I've seen. That's certainly something we can do here, but the external libraries haven't been all that active in addressing this.

I am looking into ways we can get the a11y work done on either chosen library or select2. We use chosen in lift module so we (Acquia) may be able to do at least some of that ourselves, perhaps with some help from @jessebeach.

I posted issues in both the chosen and select2 github queues.

https://github.com/harvesthq/chosen/issues/264
https://github.com/ivaynberg/select2/issues/2499

Right now select2 looks to me to be the best option for the reasons enumerated by Sun in #29 and because the maintainers or select2 have actually responded and are looking in to this issue.

Just for the record, there is existing select2 integration project: https://www.drupal.org/project/select2

Oh I should adding #1329742: Autocomplete with tagging silently discards invalid input to here. It's more than UX issue actually. There's giving diff behaviours on the frontend JS & backend PHP.

Added a comment to the select2 issue. https://github.com/ivaynberg/select2/issues/2499

Looks like it is *somewhat* accessible but needs a small amount of work on the selected options.

also @Shevchuk, have you tested yours for accessibility? If so would you consider porting it to 8 for a core patch?

The fastest way to proceed with this is probably for someone to fork select2 on GitHub.

We could then highlight what features we were using as part of Core and what would need to be done to improve it's accessibility to WCAG 2.0 AA's guidelines.

Adding ARIA is amazing. Testing with screen readers is terrific. But there is definitely more to consider when looking at accessibility of a component like this.

So let's fork one of these libraries on GitHub, ensure that the demo at least meets the low hanging fruit shown by the WAVE Toolbar and the let's see about doing some more comprehensive testing on it.

We can then ask for pull requests from the central repository. I'm not a JS guy, so I'm not doing this, but that's probably what is going to be necessary.

@mgifford

I am also not a js guy so it probably wouldn't be a good idea for me to do the work (though I will fork the repo for testing purposes).

I am looking for some people to help out with this. I'll keep you posted.

Good stuff!

Further investigation of the current implementation of autocomplete (jquery) compared to select2 shows that select2, whole not perfect, already has better accessibility than jquery.

I suggest we go ahead with select2 and fix it's few remaining accessibility bugs since select2 is at least partially accessible while jquery autocomplete is not accessible at all.

I'm not sure what you mean by jQuery autocomplete being inaccessible. It's using the same approach as we used in D7 as far as I am aware and should be quite accessible.

I'm looking again at Select2. It could also be a matter of how we want to apply it. The library is pretty powerful, but how do we want to apply it in Core? I don't think it all needs to be WCAG 2.0 AA, but we should really strive to see the parts we use are.

Kevin and I did a comparison on our machines (both MacBooks). We tried this:
- user autocomplete in node edit form in D8 - jQuery UI (Kevin)
- RDF mapping autocomplete from the RDF UI module for Drupal 8 - jQuery UI (scor)
- select2 (the demo on github) (Kevin)

We were using the Mac OS built in screenreader. We tried select2 first, which was pretty good, but both jQuery UI autocomplete tests sounded very pale next to select2.

The library is pretty powerful, but how do we want to apply it in Core?

I have identified at least 7 different use cases that would improve usability in core. I am putting them into a mockup now that I will post here.

To add to what Scor said about jquery autocomplete, when we tested autocomplete in Alpha 13 using mac screen reader the autocomplete options are not read by the screen reader when you browse them with the arrow keys, as opposed to in Select2 Where they are read, along with the number of items in the list.

Started a spreadsheet comparing features and accessibility for these libraries here:

https://docs.google.com/spreadsheets/d/1vifOGL_4wgOl6sy2Os59k24saIHvwFFQ...

Feel free to update but it already shows pretty conclusively that Select2 wins on all counts including a11y.

I also added some detail to the remaining a11y issues in email to Ivan Berg, maintainer of Select2

The remaining a11y stuff that I think would be most helpful would be adding aria-multiselectable and aria-selected (or possibly aria-checked?) attributes where appropriate. That would cover the biggest issue which is that the selected pills are not read out when tabbed over.

Next after that would be adding aria-valuemax and valuemin where minimum and maximum values are used, and adding aria-disabled for disabled values and aria-readonly for locked values.

@Everett Zufelt

If you have time could you go here and see if you encounter any issues? http://ivaynberg.github.io/select2/

The combination of documentation and demo should highlight any mismatch between what is visible and what is read out.

Also added this note to Ivan

For draggable options, those will need: aria-dropeffect and aria-grabbed (state)

I'm seeing lots of disputed inaccuracies in the comparison spreadsheet, so I don't think it's fair to make a judgement right away.

I also can't edit or comment on the spreadsheet to help adjust or correct things.

@Dave Reid

Changing permissions so you can edit

@Dave Reid you can edit

Anyone else with the link can now comment. If you would like permission to edit or you have a specific correction feel free to email me.

Ivan berg updated me on a few features that are present that I had marked no.

Select2 now shows every feature the others have and then some.

This issue really does need an issue summary update to explain concisely what the limitations are of the current autocomplete widget in core that justify its replacement. Marking "needs work" until that's done.

@webchick, I just outlined the problems with core's current autocomplete in #2346973-37: Improve usability, accessibility, and scalability of long select lists (the third bullet point).

Also, it seems that the "seeking" part is done (given #29 and Kevin's comparison spreadsheet from #61) so I'm going to close this one. See you in #2346973: Improve usability, accessibility, and scalability of long select lists :)