Posted by Dave Reid on January 6, 2010 at 5:14am
25 followers
| Project: | Drupal core |
| Version: | 8.x-dev |
| Component: | javascript |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | postponed |
| Issue tags: | accessibility, autocomplete, jQuery, jQuery UI |
Issue Summary
Let's get rid of our bad, old, custom JS and replace it with something that will be more supported, easier on the bus factor, and more flexible for development.
http://docs.jquery.com/UI/Autocomplete
http://wiki.jqueryui.com/Autocomplete
http://jquery-ui.googlecode.com/svn/branches/labs/autocomplete/
Comments
#1
+1 Subscribe. There are far too many roadblocks to the old version; the current js is lacking many useful features #365241: Add select event to autocomplete feature and has many strange bugs #590148: Autocomplete.js errors with Mozilla based browsers, due to a namespace conflicts between search terms and object properties
#2
"former"? Why was it removed?
#3
Huh, the last I read it had been removed from jQuery UI, but they're revamping its development for jQuery UI 1.8.
#4
Using jQuery UI's Autocomplete widget instead of Drupal's internal one will save us a lot of custom code.
Postponed by:
#5
The autocomplete widget is now officially in jQuery UI 1.8 Final.
#6
Unless I'm missing something, autocomplete functionality is still handled by a callback in Drupal 7.
If this is the case, then multiple values can be handled in PHP as opposed to JS.
While not optimal, it would still allow us to use the benefits of jQuery UI's autocomplete functionality, and I believe be an overall reduction in custom code.
#7
http://jqueryui.com/demos/autocomplete/multiple.html
#8
Oh dear god please!
#9
Even better:
http://net.tutsplus.com/tutorials/javascript-ajax/how-to-use-the-jquery-...
.... msonnabaum found that one.
#10
I quickly tested http://jqueryui.com/demos/autocomplete/multiple.html with FF 3.6 / JAWS 11. It doesn't seem to be any more accessible to screen-reader users than our custom solution. I would argue that we should not use the jQuery autocomplete until it is accessible. For any of the down sides to using our own we at least have the ability to improve its accessibility.
#11
FYI: #515262: Autocomplete requires ARIA for screen-reader users
#12
I posted a message jQuery UI autocomplete plugin to the jQuery-a11y mailing list. I indicated that the plugin isn't accessible and that I would be willing to help. I am not sure how much the list is used since the fforums were created. The forums are poorly accessible and I refuse to use them, rather am too annoyed with them to use them :)
#13
Excerpt of response from Scott González:
#14
Can we start to put together a list of requirements for autocomplete in D8 that we can compare with the jQuery UI multiple autocomplete component so that we can assess if it will meet our needs? This would make it easier for me to prioritize effort and to participate in the process of helping to improve the component.
#15
the jQuery autocomplete supports copy/paste search criteria too... nice :)
A starting point for requirements can be found in the older issue "Enhance autocomplete feature" here: http://drupal.org/node/125231 please let me know if is useful that i put together a wrap up of things asked there.
#16
@Marco
It would be useful to have a summary of requirements from the other issue. Please categorize them as either requirements (must have) and features (nice to have).
Thanks
#17
subscribing
#18
subscribing
And just in case someone needs the jquery autocomplete behavior for drupal 7: I've coded a module based on it: Autocomplete deluxe.
#19
This patch replaces autocomplete.js with jQuery UI's Autocomplete. Works with multiple terms, keeps the same throbber loading design, etc.
Benefits of using jQuery UI instead of our own autocomplete.js:
Note that this requires at least jQuery 1.5 to run though (#1085590: Update jQuery UI to the latest in the git repository).
#20
Fancy issue tag.
#21
#22
not sure why we needed a term change, but ok but thanks for pinging everyone
#23
Dave, well, Proudly Found Elsewhere is a nice spin on Not Invented Here. Kinda funny.
However, I thought I'd point folks to http://hanshillen.github.com/aegisdemo/
Which has a jQuery autocomplete function that has been well tested for accessibility. I do hope that this gets into jQuery's releases, but wanted to make the connection here anyways. And ya, I've posted it a few places as the demos there are pretty good. Sorry.
#24
Yeah Wim forgot to copy/paste the context of the term change in the comment. :)
#25
sub.
#26
I will be taking part in the jQuery ARIA hackathon July 11 - 12. If I can get a list of what we require in autocomplete I can see if I can get some people to spend some time ensuring that those features, at the least, are accessible.
#27
...subscribing.
#28
Everett, how did the hackathon go? Any good results from the discussion?
#29
I was unfortunately unable to attend, work got in the way.
#30
I did a very quick (30 sec) test of http://jqueryui.com/demos/autocomplete/#default using JAWS 12 and FF 6 / IE 8.
This still needs some work, I could move through the list of options and tab to select, but I wasn't notified of the search / appearance of the suggestions. If a screen-reader user isn't notified of the suggestions then they have no idea they are in an autocomplete UI control or that suggestions have appeared, as there is no access to the visual affordance, namely a list appearing on the screen.
As far as an accessibility comparison goes the jQuery autocomplete currently falls somewhere between what we have in D6 and what we have in D7.
#31
Work can totally get in the way of a good thing. Too bad that the autocomplete demo doesn't exceed what we have accomplished in D7.
So someone must have some idea of the results of this effort:
http://wiki.jqueryui.com/w/page/38817541/ARIA%20Hackathon
I searched the list but only found budget requests.
http://groups.google.com/group/jquery-team-public
Someone must be known on the jQuery list and can enquire what the result was and what the chance of advancing this ahead in the next year.
Everett, you know anyone engaged with the jQuery accessibility initiaive?
http://groups.google.com/group/jquery-a11y
#32
@mgifford I'll ask Colin Clark
#33
@mgifford: Was great getting the chance to hit Drupalcon with you. Wish I knew about that ARIA Hackathon last month in Toronto, would've loved to have gone. Everett is the only one who reached the jQuery UI team on the mailing list regarding ARIA accessibility in the library. There is an initiative out there to help with accessibility though. Since then though, the conversations have moved to the jQuery Forum: http://forum.jquery.com/developing-jquery-ui .
@Everett: If you post some of the issues you ran into, I could try to find the related issues in the jQuery UI queue and try to get patches going. Thanks.
#34
@Rob
The biggest issue, from my super fast review, was that screen-reader users have no idea that they are in an autocomplete field, or that the search suggestions have appeared.
In D7 we accomplished this with an aria live region, hidden w/ element-invisible (of course this will be visible to all w/ CSS turned off, but I'm sure that autocomplete is ugly then anyway).
When the search begins the text "Searching" is placed in the live region, when the suggestions are visible the text "Autocomplete popup" is placed in the live region. Any screen-reader supporting live regions will read this text.
I'm not quite sure how jQuery UI is making the suggestions read while arrowing through the list, my suspicion is that they are doing text replacement into the edit field. This is buggy (I experienced some bugs) as sometimes pressing the down arrow will take a screen-reader user out of the edit field. We solved this in D7 by wrapping the widget in a div w/ role="application". When in a region w/ application role screen readers pass most keyboard interaction to the browser, instead of using it to interact with the virtual buffer that is made of the page.
At the time that we committed this I mentioned that it wasn't the most elegant solution, but it does the trick for the moment.
#35
It was postponed in #4 but
#5326: jQuery UI Autocomplete doesn't support multiple itemsis an invalid bug (not the right documentation). In fact autocomplete support multiple items http://jqueryui.com/demos/autocomplete/#multipleAbout the ARIA problems: It's definitely less work to fix this on jqueryUI than maintaining custom code. With the benefit than all projects using jquerUI will be more accessible.
#36
The patch at #19 still applies cleanly and works, and supports multiple items as gagarine mentioned. It's postponed because jQuery is extremely out of date: #1085590: Update jQuery UI to the latest in the git repository
We need people to review that patch, and get it in before this one works.
#37
RE: ARIA. It looks like the Autocomplete plugin is getting a bunch of ARIA classes and attributes in both the textfield itself, and the autocomplete pop up. I personally haven't tested in the ARIA software, but it does look quite promising.
#38
@Rob
Is there a demo site where I can test the same version of jQuery UI autocomplete that we have in 7.x, or expect to have in 8.x?
#39
Here you go!!! http://8.robloach.net .... This is on a shared server, so don't get too pissed off if you see some slow performance :-) .
#40
I tested http://8.robloach.net very quickly using FF 6.0.2 / JAWS 12.
In the programming language field I typed:
j - nothing happened.
a - nothing happened
v - nothing happened
up / down arrows - nothing happened
tab - jav was in the field.
* nothing happened == I perceived nothing.
#41
Thanks for testing, Everett. Could you explain how that experience differs from using the current autocomplete field in Drupal 7? (i.e. what you would expect)
#42
@webchick
Using the D7 autocomplete:
1. Start typing.
2. Screen-reader announces 'Searching for matches...' when throbber starts.
3. Screen-reader announces 'Autocomplete popup' when the results appear.
4. Screen-reader announces each result when arrowing up and down through the list.
5. Pressing tab with a result selected populates the field with that result and moves focus to next focusable element.
#43
Sorry about that, partly my fault. I limited the auto-complete in this patch to only search if you typed more than two characters. I thought I documented that on there, guess not... Try typing "Vi", or "Ja".
#44
@Rob
I also typed a, v (that is to say 'jav' in all. :)
#45
Weird, this is what I get...
#46
My 2c for this discussion.
http://www.lullabot.com/articles/module-monday-chosen reminds of http://harvesthq.github.com/chosen/ Great usability.
edit: Duplicate #1271622: Add Chosen library to core and use wherever possible
#47
...just noting that the implementation in the demo site allows to enter the same thing(s) more than once. Don't know if this is intentional, but I think it shouldn't happen.
#48
Can someone, perhaps Everett, list out the current problems with single word autocomplete in jQuery UI either on http://groups.google.com/group/jquery-a11y or http://forum.jquery.com/developing-jquery-ui or in IRC (#jqueryui-dev on freenode)? We have a known issue where the ARIA from the menu isn't used because we keep focus in the text field. However, because the default behavior is to update the value of the text field as you navigate the menu, it appears to work, even though it's not doing what we really want. This is the cause of multi-word autocomplete completely failing for accessibility tests, since we don't update the text field. If we can work through the single word issues, we might get multi-word support automatically.
#49
@Scott
Can you please provide me a link to a demo of the most recent stable snapshot of jQuery UI autocomplete? It doesn't need to be a release, since we are planning this for the D8 release, which is quite a way away.
#50
Can't wait for this! Would love to see
formatItem,formatMatch, andformatResultsupport!http://docs.jquery.com/Plugins/Autocomplete/autocomplete#url_or_dataoptions
#51
See #1322664: Add support for formatResult, formatItem and formatMatch in autocomplete.js
#52
@Scott pointed me to http://view.jqueryui.com/ off list. I have a tentative plan to do a full jQuery UI accessibility evaluation, including autocomplete, the week of Nov. 7.
#53
This is totally a good call. I've posted a note about this and hope to get some more feedback & encourage participation.
#54
See http://zufelt.ca/blog/jquery-ui-accessibility-review-whats-plan#comment-334 for a very quick review of jQuery UI autocomplete 1.9pre (master) w/ Firefox 7 and JAWS 13.
Still not suitable for D8, but can possibly be fixed w/o too much effort.
#55
Thanks for the review, Everett. Could you put together an action list of ARIA roles that would have to be added to the markup to help improve this? Considering there's an abundant lack of JAWS/ARIA markup documentation around, it makes it really hard to come up with a solution around it. Without a proposed solution, this just becomes a huge bikeshed.
Thanks.
.... Also, here's a review of your review:
The custom data demo is a demonstration of returning custom data back and displaying it in a fancy way. You can see this example gives you a title and a description below it. We won't be using this in Drupal's autocomplete widget.
The Categories demo shows you how to split results into different categories. It gives you different results in a set number of categories. Your listing of "andreas johnson" is provided under the "People" category. Again, this is not something we'll be using for the Drupal autocomplete widget.
Are there any roles that we could inject here to help the process? You're not really providing any direction. The demo for 1.9m6 gives you the "aria-activedescendant" attribute that will tell you where it is.
..... So, from the autocomplete review, it sounds like you ran into three issues. Two of them were issue with you not understanding what the demo was, and the third I have no clue what is wrong. More details and direction would be great.
#56
Rob
Thanks for the feedback. As the article clearly states I will be filing bugs against the relevant components at the end of each day. I will provide a link to the bug(s) filed against autocomplete here.
#57
Awesomesauce!
#58
http://bugs.jqueryui.com/ticket/7840
#59
Keeping up to date now that jQuery 1.7 is in there... Would be nice to have:
#60
As far as I know, jQuery UI autocomplete will not be accessible enough for Core until at least 1.9.
#61
http://bugs.jqueryui.com/ticket/7840#comment:9
Could use review and feedback.
#62
The last submitted patch, 675446.patch, failed testing.
#63
Everett, does that mean that our current autocomplete is better (accessibility-wise) than the jQuery UI autocomplete? If this is an improvement from the current situation, it seems like it should go in whether it's fully accessible or not.
#64
@quicksketch
Drupal 7 autocomplete.js is significantly better than the current jQuery UI autocomplete. We are going to attempt to follow the Drupal 7 approach in jQuery UI, I just don't have enough hours in the day to re-roll the current jQuery UI patch.
#65
+++ b/core/misc/autocomplete.js@@ -5,318 +5,65 @@
+ search: function() {
+ // Only search if there has been more then two characters in there.
+ var term = Drupal.autocompleteextractLast(this.value);
+ if (term.length < 1) {
1) While a minimum of 2 sounds good as default, the minimum term length should be configurable per autocomplete widget.
2) It looks like the code does something else than the comment states; it checks for non-zero length instead of 2.
+++ b/core/misc/autocomplete.js@@ -5,318 +5,65 @@
+ focus: function() {
+ // Prevent value inserted on focus.
+ return false;
+ },
+ // It will select the search term based on the last item in the list.
+ select: function(event, ui) {
+ var terms = Drupal.autocompletesplit(this.value);
+ // Remove the current input.
+ terms.pop();
+ // Add the selected item.
+ terms.push(ui.item.value);
+ this.value = terms.join(", ");
+ return false;
}
I'm seriously surprised that all of this custom code is needed...? That belongs to the bare essentials of autocomplete functionality, so why is that needed, and that is jQuery UI's Autocomplete plugin actually doing, if we even need custom code for the most basic functionality...?
+++ b/core/misc/autocomplete.js@@ -5,318 +5,65 @@
+ // Pop up the autocomplete if tab was entered.
+ $(this).bind('keydown', function(event) {
+ if (event.keyCode === $.ui.keyCode.TAB && $(this).data("autocomplete").menu.active) {
+ event.preventDefault();
}
});
Not sure whether this is needed.
+++ b/core/misc/autocomplete.js@@ -5,318 +5,65 @@
+Drupal.autocompletesplit = function(val) {
+ return val.split(/,\s*/);
+};
+Drupal.autocompleteextractLast = function(term) {
+ return Drupal.autocompletesplit(term).pop();
};
This looks like a regression to me - Drupal's autocomplete syntax supports commas within terms; e.g.:
"Boston, USA", "Karlsruhe, Germany"Support for the term delimiter within terms is one of the main problem spaces for autocomplete/string parsers. That's why approaches like jQuery Tokeninput or jQuery UI ListBuilder, which convert and shift away all the existing terms outside of the input field, are much more reliable and mature.
#66
Tagging. Also wanting to point folks here - http://drupal.org/node/1175830#comment-5747762
jQuery's the right place to do this.. So let's make sure jQuery's accessibility keeps ahead of (or at least keeps up with) Drupal's.
#67
I haven't done full testing, but I did test a bit, and it looks like the autocomplete now in jQuery-UI 1.9 (master branch) will have sufficient accessibility for D8.
http://bugs.jqueryui.com/ticket/7840
#68
Let's post-pone this for #1085590: Update jQuery UI to the latest in the git repository then :-) .