When typing into an autocomplete field it would be good if the search text typed into the text field, is emboldened in the autocomplete suggestions as follows:

So, if I type 'F', then the following might show:

  1. Food
  2. Buffoon
  3. Faffing

NOTICE: The bold F's in the above.

I believe for sake of sensibility, only the first 'f' in this case should be emboldened in the autocomplete suggestions (note I would actually use around the F's in this case, with a css class, so people could style it as bold or a colour or whatever they want).

Then if I typed 'o' after the F, the text in the textfield would then be 'Fo', so the following suggestions would show:

  1. Food
  2. Buffoon

NOTICE: The bold 'Fo' text in the above.

I got this half working with the current functionality, i.e. I can do a preg_replace() in the autocomplete callback, for the first occurrence of the search term, and add html bold tags around that search term in the suggestions. This works, however when I then select an autocomplete suggestion, then the textfield will be populated with the HTML also. e.g. <b>Fo</b>od rather than Food.

Members fund testing for the Drupal project. Drupal Association Learn more

Comments

CatsFromStonehenge created an issue. See original summary.

CatsFromStonehenge’s picture

shylajaphp’s picture

Hi CatsFromStonehenge,

I think you have to add a div tag instead of the textbox and before submitting the search form, you have to dynamically set the text value.

cilefen’s picture

Component: field_ui.module » base system
Issue tags: -autocomplete +JavaScript
CatsFromStonehenge’s picture

The function in the following file needs changing from:

/core/misc/autocomplete.js

function renderItem(ul, item) {
return $('<li>')
  .append($('<a>').html(item.label))
  .appendTo(ul);
}

to:

function renderItem(ul, item) {
return $("<li>")
  .attr("data-value", item.value)
  .append($("<a>").html(item.label.replace(new RegExp(this.term, 'i'), "<span class=\"autocomplete-search-term\">$&</span>")))
  .appendTo(ul);
}

If nobody adds styling, then no change in behaviour will be noticed. Otherwise if they add styling as follows:

/* Autocomplete styling */
.autocomplete-search-term {color: orange;}

In this example the search term will be marked as orange within the autocomplete suggestions. See the attached file Styled Autocomplete Suggestions.png to see what it looks like in action.

How do I propose this change to the gurus above? ;-) Thanks!

Mike

CatsFromStonehenge’s picture

I forgot to credit someone's solution from a couple of years ago from here (user2811483):
https://stackoverflow.com/questions/26189673/jquery-autocomplete-how-to-...

CatsFromStonehenge’s picture

shylajaphp’s picture

Hi CatsFromStonehenge,

Please create a patch file of /core/misc/autocomplete.js and upload it here and set the status as needs review so that community members can review it.

droplet’s picture

Issue tags: +Usability, +ux
CatsFromStonehenge’s picture

@shylajaphp I've added a patch file. I hope that's right, it's my first go!

CatsFromStonehenge’s picture

Status: Active » Needs review

Status: Needs review » Needs work

The last submitted patch, 10: autocompleteusability-2864278-12009514.patch, failed testing.

CatsFromStonehenge’s picture

Hi

Does anyone know how I find it why a patch failed testing? I'm trying to fix the issues.

If it's an automated test that failed, then all ok. Just hoping for some constructive feedback. Thanks.

Needs work If the patch does not meet all the above criteria, you should still thank the contributor for the work and identify what is done correctly. Explain what is problematic in the patch and add any helpful information you can provide from your testing. Change the issue status from "Needs review" to "Needs work." See How to give constructive feedback.

https://www.drupal.org/patch/review

shylajaphp’s picture

cilefen’s picture

It was a JavaScript coding standards violation. See the checkstyle result. https://dispatcher.drupalci.org/job/drupal_patches/8440/

CatsFromStonehenge’s picture

CatsFromStonehenge’s picture

CatsFromStonehenge’s picture

cilefen’s picture

I would set this to "needs review" so the testbots will test it, however, the coding standards issue remains unfixed in #17. Also, interdiffs are appreciated.

CatsFromStonehenge’s picture

Thanks Cilefen.

I had implemented those test fails quite soon after you said, and uploaded the 'git diff' file, but then I noticed some usual behaviour. I put autocomplete.js back to it's original form (before my changes) but the problem still remained with 8.4, i.e. when I setup an autocomplete textfield on Drupal 'titles' (e.g. article titles, page titles etc) and I select one of the suggestions, I get double quotes appearing around the chosen string, that is then inserted into the textfield. I'm confused, as this seems like a big coincidence that the behaviour has changed from 8.2 to 8.4 (I had been developing in 8.2, but I did the testing on 8.4).

So until I can absolutely confirm it wasn't something I've done, then I don't want to move forward quite yet.

Can anybody else confirm the double quote issue on a fresh install? (installed via git / composer on latest 8.4). Just to confirm: if you select an autocomplete suggestion like Mammals, Apes, Monkeys it populates the textfield as "Mammals, Apes, Monkeys".

I've only been looking at Drupal 3-4 weeks, so I'm not fast or confident enough yet to blaze on through. Caution is good I think. I'm OK, with my changes, but concerned about the double quote issue that has been introduced. I'm fairly sure it's not me, but I want to be 100% sure.

I tested on Safari, Chrome and Firefox on a Mac. The issue occurs on all of these.

CatsFromStonehenge’s picture

OK, so I did a completely clean install and the double quote issue I discovered while testing, still occurs (but only in 8.4, and not 8.2). My bug report for this is here: https://www.drupal.org/node/2864807

I don't think this is to do with the autocomplete core code, but it's a side-effect of something else.

CatsFromStonehenge’s picture

I've confirmed it's not an issue with the changes I made on my local platform. The bug shows up in autocomplete, but doesn't seem to originate within autocomplete's code. I just wanted to be play safe before charging in with my changes.

I'll now add my previous updates to be inline with coding standards for quotes. Saved again by Cilefen!

CatsFromStonehenge’s picture

p.s. I think if this change goes through, then the styling should default to:

.autocomplete-search-term {font-weight: bold}

on a fresh install. Just my opinion... I think it gives more clarity to the user from a usability standard.

As an aside, I might ask the jQuery team to add this somehow... their demo doesn't make the search term stand out in the autocomplete suggestions given. See here: https://jqueryui.com/autocomplete/

However the largest website I can think of that uses autocomplete, is http://www.rightmove.co.uk/. They do make the search term stand out in autocomplete suggestions. To give some background on why I came to the same decision as Right Move, is that I had a lot of data (38,000+ records) that I was using for autocomplete. When a list of 10 suggestions came up for autocomplete, it wasn't always immediately obvious at a quick glance why they had shown up... especially if the search term was 1-3 characters. I believe usability should make the user's own processing time (not their CPU, I mean their actual personal processing time when looking at a user interface) should be reduced to a minimum. Every small change that makes it slightly more intuitive / easier for an end-user is a good thing I think. Lots of small annoyances, can add up to a terrible web browsing experience.

This needs debating of course. If the style is emboldened by default, then people can always override that styling to none, however from a usability perspective I'm not sure why someone would want to do that.

Again this is up for debate, with others.

droplet’s picture

It may need the em tag instead.

Could you add the style and then tagging "Needs usability review".

We need a JS Tests also if UX reviewers are happy with it.

CatsFromStonehenge’s picture

Great idea @droplet. The em is far more suitable. Change coming now.

I'll try to look into how to write JS Tests next... I'll also presumably need to update some documentation at some stage, so people know about the change.

CatsFromStonehenge’s picture

CatsFromStonehenge’s picture

cilefen’s picture

Status: Needs work » Needs review

Set them to "needs review" when you upload a patch.

CatsFromStonehenge’s picture

Apologies Cilefen. It looks like this is set to 'Needs Review' now. Did you do that for me? If so appreciated.

Thanks for training me up on this. It feels great to have got this far in a month! A lot more to learn though! Exciting stuff.

CatsFromStonehenge’s picture

This feature now needs testing by the community, so I can change the status to 'Reviewed & tested by the community'.

Any volunteers? :-)

The patch is fairly simple. I can take anyone through getting autocomplete working, if they've not used it before and are struggling. So support given my end.

Thanks!

droplet’s picture

Status: Needs review » Needs work
Issue tags: +Needs usability review

Asking for UX reviewers. The patch is incomplete but the IS was very clear to show the directions.

  1. +++ b/core/misc/autocomplete.js
    @@ -201,7 +201,8 @@
    +      .attr('data-value', item.value)
    

    I need to confirm what that is.

  2. +++ b/core/misc/autocomplete.js
    @@ -201,7 +201,8 @@
    +      .append($('<a>').html(item.label.replace(new RegExp(this.term, 'i'), '<em class="autocomplete-search-term">$&</em>')))
    

    EM rendered as italic now. I think bolded without italic would be better.

Bojhan’s picture

Issue tags: -Needs usability review

This looks like a common pattern, so looks good :)

Bojhan’s picture

This looks like a common pattern, so looks good :)

droplet’s picture

Issue tags: +Needs JS testing

Thanks @Bojhan!

Let's add JSTest and fix the style and move on!

jussielo’s picture

FileSize
495 bytes

I tested the patch but italic text is quite hard to spot from the middle of text. I changed the em tag to strong tag which makes the query string easier to spot.

miwayha’s picture

Issue summary: View changes
Issue tags: +accessibility

I'm adding the accessibility tag, because when I run this with my screen reader, it has the potential to affect how the search results are announced.

Taking the three examples from the summary, VoiceOver pronounces the words:

  1. ef - ood
  2. boo - ef - foon
  3. ef - affing

and then the ones with "fo":

  1. foh - odd
  2. buff - foh - on

That change should be weighed.

jussielo’s picture

FileSize
575 bytes

I tested the accessibility problem addressed by @miwayha and updated the patch with an accessible solution.

The <a> tag is given an aria-label attribute and the contents of the link are hidden with aria-hidden. This makes screen readers to read the label and ignore the contents.

andrewmacpherson’s picture

FileSize
621 bytes

Attaching interdiff for the patch in #37

andrewmacpherson’s picture

There was a syntax error in the patch in #37, a missing closing ).

New patch and interdiff here.

andrewmacpherson’s picture

I really like the general usability improvement in this feature request!

@miwayha, @jussielo - I'm unable to replicate the problem described in comment #36. Can you provide details of which version(s) of OS, browser and screen reader you heard the problem with?

Also, what kind of autocomplete field? Just want to be sure I'm testing the right thing. I used the Standard install profile, created 3 terms in the default "tags" vocabulary, then used the tags field on the article node form. It's an "Autocomplete (Tags style)" field widget.

I've tested the patches from #26 and #35, applied against 8.4.x. with the following browser/screeenreader combinations, and I can't reproduce the broken-up pronunciation.

  • macOS 10.12 Sierra + Safari v10 + VoiceOver
  • macOS 10.12 Sierra + Chrome v57 + VoiceOver
  • Kubuntu 16.10 + Chrome v57 + ChromeVox

The jQueryUI autocomplete works by appending divs to <span class="ui-helper-hidden-accessible" role="status" aria-live="polite" aria-relevant="additions">. These additions don't include the <strong> wrapper elements. So I'm not expecting to hear any broken-up pronunciation, and the report in #36 surprises me.

I'm unable to get VoiceOver to read out the list items from <ul class="ui-autocomplete ui-front ui-menu ui-widget ui-widget-content" id="ui-id-1"> which contain the <strong> wrapper elements. I'm not expecting to be able to, as the UL gets display:none when the voiceover cursor moves from the text input. The "Enter a comma-separated list..." help text gets the VoiceOver cursor instead.

@jussielo's approach with aria-hidden and aria-label (patches #37, #39) doesn't affect the text that is added to the span.ui-helper-hidden-accessible live region either.

From my own testing, the approach in patch #35 seems acceptable to me.

andrewmacpherson’s picture

Tagging for the accessibility gate. I haven't found any bad behaviour myself, but would like to replicate (or rule out) the behaviour reported in #36.

miwayha’s picture

Ah I realize now my initial comment was misleading:

I had my screen reader read the issue description and encountered the bad behavior, and I wanted to raise the possibility that the phenomenon could also happen in the autocomplete itself. I still think having an accessibility review is the right thing. But, I should have been more clear that I was asking whether this had an impact on screen readers based on how my VoiceOver read the proposed markup in the issue summary, rather than actually reporting that I had actually fund a problem with the patch. Apologies for the confusion.

(I've been having trouble installing 8 locally, but I'll give it another try and see whether I can see the issue with the applied patch.)

miwayha’s picture

I'm not encountering the bad behavior when I apply the patch.

I guess one frustrating and confusing thing is why I don't get the bad behavior even when I change autocomplete.js such that the markup is identical to what is in the issue summary on this page.

jussielo’s picture

Page structure makes verifying the accessibility issue problematic. Autocomplete suggestion box is placed in code at the end of the page and not semantically as the next element. You can get to the suggestion box by using VoiceOver keyboard commands but it's a long way to go through multiple elements.

Anyone still interested in fixing the patch to move the suggestions to the semantically correct location?

andrewmacpherson’s picture

@miwayha:Thanks for clarifying in #42. We can put the report in #36 down as a red herring :-)

I've tested this with a number of screen readers, before and after the patch. I'm happy that the approach in patch #35 is a safe change we can introduce, so removing the "needs accessibility review" tag. I haven't tested in JAWS yet, but based on what I've seen so far it's low risk.

@jussielo:

Anyone still interested in fixing the patch to move the suggestions to the semantically correct location?

I don't think we should do that here - it would be a big change to the scope of this issue. The suggestions are announced by means of a separate aria-live region, which is updated by the arrow keys. So there's no reason to actually visit the results box itself.

Longer term, it's worth exploring more robust ARIA patterns, such as the combobox role and aria-activedescendant. The WAI-ARIA Authoring Practices will eventually have a recommended pattern for this, but it's still in development, and ARIA 1.1 is bringing some important changes to the combobox role. That's a bigger job which deserves it's own follow-up issue, and we'll probably have to wait until browser support is better.

droplet’s picture

+++ b/core/misc/autocomplete.js
@@ -201,7 +201,9 @@
+      .append($('<a>').attr('aria-label', item.value)

item.value should be item.label

ref: #2868299: Improve autocomplete renderItem() docs

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.