Before going any further, know this:
Much of the work on this task took place here: #2346973: Improve usability and accessibility of long select lists. It eventually became apparent that this needed its own issue
- Are you looking for the issue regarding a drop-in replacement for jQuery UI autocomplete, for stuff like entity reference fields? this is that issue
- Are you looking for the issue regarding UX improvments to
<select>elements, making it easier to deal with long lists of options? That is a different issue, and it is here: #2346973: Improve usability and accessibility of long select lists
Problem/Motivation
We are in the process of deprecating jQuery UI in core. jQuery UI's autocomplete is among the components that need to be removed/replaced.
As mentioned in the parent issue: #3067261: [Plan] Remove jQuery UI components used by Drupal core and replace with a set of supported solutions
The OpenJS Foundation lists jQuery UI as an Emeritus project in https://openjsf.org/projects/ which is described as:
Emeritus projects are those which the maintainers feel have reached or are nearing end-of-life
Well before the need to deprecate jQueryUI emerged in mid-2019, there has been interest in replacing jQueryUI with something with better UX and accessibility (which is evident in this issue being created several years prior to mid-2019).
Proposed resolution
First, some context regarding the decisions made in this specific resolution
Because it was clear the new autocomplete would not be fully backwards compatible with jQuery Ui autocomplete, it was decided to introduce the new Autocomplete as an experimental module and leave jQuery UI autocomplete as the default until Drupal 10. This would provide sites with adequate time to make any changes required
The original plan for this was to replace jQuery UI with another library. Awesomplete was literally the only library without significant accessibility regressions compared to jQueryUI and one that could be added with the least disruption so that was the library we chose.
It was then observed that the amount of customization required for the Awesomplete implementation was significant enough that we were using very little of the library itself, and it may be simpler to make the solution entirely custom.
Then after that, it was observed that this new autocomplete may be a good candidate for being a standalone library that doesn't depend on Drupal, which would adhere to the policy being discussed here (once fully defined): #3176918: [policy, no patch] Publishing / Maintaining JS libraries produced by Drupal that do not have a dependency on Drupal
With that context out of the way, this is the current proposed solution
How it will work in Drupal:
- The majority of the functionality resides in a custom JavaScript class that does not depend on Drupal and adheres to the policy defined in #3176918: [policy, no patch] Publishing / Maintaining JS libraries produced by Drupal that do not have a dependency on Drupal. As this policy is still in progress, circumstances encountered while working on this may inform that policy.
- Drupal-specific functionality such as calls to Drupal.t() and Drupal.announce() will take place in a different file. Class methods will be overridden as needed.
- The module (but not the library) may include copies of CSS styles that are only present in jQueryUI files (or jQueryUI extending files such as theme.css). This is to prevent style regressions when jQueryUI is actually removed.
- JqueryUI classes should be added via options/overrides so the markup is as similar to jQueryUI as possible, except in instances where there are clear benefits to changing that markup.
- When there are benefits to changing the markup, theme-specific autocomplete styles may need to be adjusted to accommodate these changes, such as the
<li>receiving focus in the new autocomplete vs an<a>receiving focus in jQueryUI. - Accessibility implementation will use Accessible Autocomplete from GOV.UK as reference, as it was informed by extensive testing and research. (the accessible autocomplete library was not an option as something Drupal could use as the feature set did not cover what core would need from an autocomplete.
How it will be introduced and ultimately replace jQuery UI autocomplete:
- In Drupal 9.2, The jQuery UI autocomplete replacement will be provided in an Experimental module named Drupal Autocomplete. As with all experimental modules, it will not be enabled by default. This module will be available so Drupal 9 sites can switch to Drupal's new no-jQuery-UI when they see fit.
- Also in Drupal 9.2, jQuery UI autocomplete will be deprecated for removal in Drupal 10.0
- In Drupal 10.0, The autocomplete functionality provided by the Drupal Autocomplete module will replace it. The Drupal Autocomplete module will be removed as the functionality it provides would now be Drupal's default.
- Since Drupal Autocomplete will be removed from Drupal 10, it's not essential that the module move from Experimental to Stable. However, I think it would be good to make a promotion to stable in Drupal 9.6 a very-nice-to have as it will: 1) Likely address governance issues that would otherwise arise during the "crunch time" leading up to D10 deadlines 2) Encourage more sites to enable the module sooner. 3) Provide sufficient time for sites that have enabled Drupal Autocomplete to report issues that would be addressed in the Stable release.
Steps taken prior to the proposed resolution
Several other options were evaluated. Note that all links to evaluations go a separate issue: #2346973: Improve usability and accessibility of long select lists, the issue that this originated from.
- https://github.com/jshjohnson/ChoicesEvaluation (#189)
- https://harvesthq.github.io/chosen/Evaluation (#194)
- https://github.com/Mobius1/SelectrEvaluation (#195)
- https://github.com/alphagov/accessible-autocomplete (prototype at #182, great accessibility but not considered as it does not support select/multiselect It is strictly for providing suggestions to single-value text fields)
- https://github.com/HemantNegi/jquery.sumoselectEvaluation (#201)
- http://ivaynberg.github.io/select2 (of which https://github.com/woocommerce/selectwoo is a fork of, created to improve accessibility) Evalulation (#193)
- Custom library based on https://react-select.comEvaluation (#200)
- https://selectize.github.io/selectize.js/Evaluation (#199)
- https://leaverou.github.io/awesomplete/Evaluation and prototype (#223)
- https://github.com/github/auto-complete-elementEvaluation (#222)
Other than Awesomplete, nontrivial accessibility problems identified in each evaluation. These problems were discovered from general accessibility testing. In each case, enough issues were found that it wasn't worth devoting additional time to strictly checking against W3 specs.
Remaining tasks
- Accessibility review
- JS review
- FE Manager review
- UX review
- Product Manager review
- (probably more reviews, this is a major change)
User interface changes
Yes.
API changes
Yes.
Release Notes Snippet
A new experimental module, Drupal Autocomplete, has been added. It replaces the functionality provided by jQuery UI Autocomplete, as jQuery UI has reached end-of-life. The functionality provided by this module will be default in Drupal 10, so we encourage all sites to enable this module as soon as possible. Sites that have no autocomplete customization should be able to enable this module with zero disruption. Sites that do customize autocomplete behavior should use this module to prepare their site for Drupal 10.