Auto suggest causes significant accessibility issues for using basic search in some browsers

Bug #1187993 reported by Kathy Lussier on 2013-06-06
28
This bug affects 5 people
Affects Status Importance Assigned to Milestone
Evergreen
High
Unassigned

Bug Description

As was noted in a searchbar.tt2 comment from commit http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=aaf2d7f5f4ecd7dd36d5aee5ced23de78712ff62, autosuggest breaks accessibility, as the aria-label
attribute is removed when the Dijit is created.

We received a report from a patron that she is no longer able to conduct a search in the catalog when using the JAWS screen reading program. She previously had success searching the catalog a few months ago, and we traced it to the implementation of auto-suggest in the C/W MARS catalog.

I don't know if the same problem occurs in other screen reading programs, and I personally don't have much experience with JAWS, but, in my own testing, I found that the accessibility problems makes it extremely difficult to conduct any kind of basic or searchbar search in IE and, to a lesser extent, in Google Chrome. Although Firefox also doesn't see the aria-label attribute, I was able to use all of the JAWS options that were problems for the other two browsers.

Since our catalog is a 2.3 catalog, I did a bulk of my testing in http://laurentian-test.concat.ca (thanks to Dan Scott for sharing the link to his test server!) and in http://sclends.lib.sc.us/ as both are 2.4 systems using auto-suggest. As a contrast, I also conducted similar tests in the MVLC and Bibliomation catalogs, both of which are 2.4ish systems that have not enabled autosuggest. The MVLC and Bibliomation catalogs did not encounter any of the problems described below.

 Testing in IE 10:
1. When arriving to the catalog search page in IE10, the cursor often started in the text search box, but this didn't happen consistently. For example, when clicking the "Another Search" link to return to the home page, you were less likely to land in the search box. If the cursor immediately landed in the search box, then the JAWS user could easily type the search terms and conduct the search.

However, if the cursor didn't land in the search box or if the user moved the cursor away from the search box, it's nearly impossible for the user to return to the search box without visual assistance as a result of the following two problems:

2. A JAWS user typically can use the "F" key as a shortcut to navigate to different form elements or can use the "E" key as a shortcut to find an edit box. Both of these shortcuts offer a quick way to find the text-entry box on the basic search page or the search bar. The user should then be able to hit the <Enter> key and then type their search terms. After hitting <Enter> in the catalog, though, the typed search terms do not appear in the search box. However, JAWS reads the letters aloud as if they are successfully being entered in the search box. From the perspective of the visually-impaired user, it sounds as if the search terms are being entered correctly even though they really aren't appearing in the search box. When the user then tries to conduct the search, it fails because Evergreen sees it as an empty search.

3. A more tedious method to find the search box is to use the <Tab> key to navigate through all of the elements on the page. However, this is also problematic in the auto-suggest-enabled catalog because JAWS isn't properly identifying the search box as an "Edit Combo" box where the user can type a query. Instead, it identifies the element as whatever the previous element was that was touched by the tabbing. In the case of the Conifer Test server and the SC LENDS catalog, it identifies it as a combo box in both forwards and backwards tabbing since combo boxes immediately precede and follow the search box. However, in the C/W MARS catalog, the "Advanced Search" link immediately precedes the search box, so JAWS is identifying the search box as "Advanced Search link." In all of these cases, the user has no way of knowing they have reached some kind of text entry box where they can enter their search terms.

Testing in Google Chrome 27.0.1453.94:

Google Chrome demonstrated similar behavior to the above with the exception of problem 3. When tabbing through the results in Chrome, JAWS is able to identify the text box as an "Edit Combo" box. However, this isn't an ideal way for the user to locate the text-entry box.

Some temporary workarounds that were identified in IRC today:

Disabling javascript - preliminary testing showed improvement disabling the use of javascript in the browser. However, it still wasn't working as well as the catalogs that had autosuggest disabled altogether.

Using Firefox - testing with Firefox 21 yielded much better results than the other two browsers.

Directing users to advanced search - Since autosuggest isn't implemented in the advanced search screen, I didn't encounter the problems found above. However, Dan Scott also mentioned in IRC that advanced search has other accessibility issues, putting you "in a maze of twisty little boxes, all alike"

Kathy Lussier (klussier) wrote :

They say a picture is worth a thousand words. Since most people don't have JAWS installed on their computers, I thought it might be useful to create a brief screencast showing the extent of the problem when using IE on a catalog where autosuggest is enabled. http://www.screencast.com/t/ap5XiwI3r. The user who initially reported the issue to us expressed a great deal of frustration over the fact that she couldn't perform a search.

I also tried some tests with other screen reading solutions. The autosuggest-enabled catalog works well in Chrome when using the ChromeVox extension. Using Windows Narrator with IE is problematic. When tabbing to the search box, Narrator remains silent.

Ben Shum (bshum) on 2013-07-25
Changed in evergreen:
status: New → Confirmed
importance: Undecided → High
Bill Erickson (berick) wrote :

Anyone know if JAWS works with HTML5 datalist elements?

http://www.w3schools.com/html/html5_form_elements.asp
http://www.w3schools.com/html/tryit.asp?filename=tryhtml5_datalist

If so, we could potentially remove the Dojo requirement without having to implement an ad-hoc combobox (or having to import a different JS UI lib).

Kathy Lussier (klussier) wrote :

I don't have an answer to your questions, Bill, but if you know of some example sites that use HTML5 datalist elements to build an autosuggest feature, I would be willing to ask somebody to try it out with JAWS to see if they encounter any problems.

Bill Erickson (berick) wrote :

Thanks, Kathy. The w3schools link -- http://www.w3schools.com/html/tryit.asp?filename=tryhtml5_datalist -- has a dataset example on the right side of the page. It's not "auto", exactly, because it uses a fixed data set (instead of JS), but the "suggest" part is there. If that page works with JAWS, I would expect the "auto" version to work as well, since the HTML elements are the same.

Dan Scott (denials) wrote :

w3schools, Bill... really? :)

That said, both w3schools and the more authoritative https://developer.mozilla.org/en-US/docs/Web/HTML/Element/datalist note that Safari (desktop and mobile) does not support the <datalist> element.

I imagine this would be a blocker; that said, we could explore a polyfill or the graceful degradation approach suggested at http://adactio.com/journal/4272/ instead (it would not be an elegant experience for Safari users, but hey... c'mon Safari/WebKit, datalist was added to HTML5 *4 years ago*!)

Bill Erickson (berick) wrote :

Haha, sometimes I'm lazy, Dan. Besides, w3s posts functional examples, so they have that going for them, which is nice...

Thanks for the graceful degradation link/suggestion. I'll try to give Safari a poke with some of this today.

Mike Rylander (mrylander) wrote :

While these may not be blockers to using <datalist>, I think they're significant issues that should be considered, roughly in priority order:

 1) Worst, <datalist> is always left-anchored, but our autosuggest is search-based with best-match ordering
 2) We can't control the formatting of the display with CSS or HTML
  2a) We lose highlighting, which was a big part of the original request, and helps to draw the user's eye based on overall matchiness and left-matchiness
  2b) The class/field marker on the right is probably OK, because the text content of the <option> is displayed where we place it by default (though we can control it today with autosuggest)

(1) is the biggest problem, by far. It would significantly reduce usability of the feature, IMO.

Yamil (ysuarez) wrote :

My institution paid for the auto-suggest development (Berklee College of Music). Let me know how we can help with fixing this feature. At some point I can bring in a visually impaired faculty member to assist us too.

Bill Erickson (berick) wrote :

For reference, here's a jquery implementation confirmed to work with JAWS 14, NVDA, and VoiceOver:

http://www.bu.edu/webteam/clrux/accessibility/autocomplete/autocomplete.html
http://api.jqueryui.com/autocomplete/

I'm not suggesting we use (or not use) jquery, only that we may be able to learn from this example and/or borrow some code.

Jason Stephenson (jstephenson) wrote :

I don't mind if we learn from the jQuery example, but I do not need another JavaScript framework to have to learn just to work in Evegreen. If you can come up with an Angular.JS solution, I would be all for it.

Bill Erickson (berick) wrote :

I smell what you're cooking, Jason. Just to be clear, if we introduce a new JS framework to the catalog, it should (must, IMO) coincide with removing Dojo. Since autosuggest was the reason Dojo was reintroduced to the catalog, replacing Dojo as we replace autosuggest is a natural fit. (All of the other Dojo code in the catalog, IIRC, is limited to things like dojo.byId(), etc., stuff that's easy to replace).

Regarding JQuery, Angular uses a subset of jquery internally. On page load, it checks for the presence of jquery proper and if it's not found, it activates its own jquery shim code. Blending the two together is not unheard of. Based on what I've seen in the wild, I'd say that combining them is what most people do. I have avoided loading jquery so far in the staff client code, relying instead on the angular shim, because jquery seemed unnecessary. If it serves a larger purpose (e.g. autosuggest), maybe it's warranted. *long shrug*. Of course, new dependencies mean additional version maintenance, etc., etc.

With a cursory search, I'm finding lots of Angular typeahead plugins and tutorials, but the only ones that address accessibility specifically that I've found use JQuery / Angular+Jquery. (Speaking of, here's a worthy read: https://webaccessibility.withgoogle.com/unit?unit=6&lesson=13). I'm still digging...

Bill Erickson (berick) wrote :

Looking at this from the opposite direction, it may be possible with less work to monkey-patch the Dojo bits we need to make them work. Before going too far down that road, though, I wonder if anyone has or would be able to test JAWS, etc. against modern Dojo. The first example here is a good one to test: http://dojotoolkit.org/reference-guide/1.9/dijit/form/ComboBox.html

If modern Dojo resolves the worst issues (note: some remaining issues are listed at the bottom of that page), it may be possible to take bits of the newer ComboBox-related files and insert them sideways into Evergreen.

Download full text (6.8 KiB)

I would recommend also checking it with GW Micro's Windows-Eyes screen
reader. It's not as well known as standards like JAWS but that's likely to
change because they're partnering with Microsoft now to make it free for
anyone who owns a license of Office 2010 or later. It's being promoted
through state Talking Book services programs and others.

The web address for the free download is:
http://www.windoweyesforoffice.com/

JAWS and other ZoomText will probably still be used by institutions who
already have them but this will probably gain a lot of traction among those
looking for a free(ish) product.

On Thu, Apr 17, 2014 at 10:05 AM, Bill Erickson <email address hidden>wrote:

> Looking at this from the opposite direction, it may be possible with
> less work to monkey-patch the Dojo bits we need to make them work.
> Before going too far down that road, though, I wonder if anyone has or
> would be able to test JAWS, etc. against modern Dojo. The first example
> here is a good one to test: http://dojotoolkit.org/reference-
> guide/1.9/dijit/form/ComboBox.html
>
> If modern Dojo resolves the worst issues (note: some remaining issues
> are listed at the bottom of that page), it may be possible to take bits
> of the newer ComboBox-related files and insert them sideways into
> Evergreen.
>
> --
> You received this bug notification because you are subscribed to
> Evergreen.
> Matching subscriptions: evergreenbugs
> https://bugs.launchpad.net/bugs/1187993
>
> Title:
> Auto suggest causes significant accessibility issues for using basic
> search in some browsers
>
> Status in Evergreen - Open ILS:
> Confirmed
>
> Bug description:
> As was noted in a searchbar.tt2 comment from commit
> http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=aaf2d7f5f4ecd7dd36d5aee5ced23de78712ff62,
> autosuggest breaks accessibility, as the aria-label
> attribute is removed when the Dijit is created.
>
> We received a report from a patron that she is no longer able to
> conduct a search in the catalog when using the JAWS screen reading
> program. She previously had success searching the catalog a few months
> ago, and we traced it to the implementation of auto-suggest in the C/W
> MARS catalog.
>
> I don't know if the same problem occurs in other screen reading
> programs, and I personally don't have much experience with JAWS, but,
> in my own testing, I found that the accessibility problems makes it
> extremely difficult to conduct any kind of basic or searchbar search
> in IE and, to a lesser extent, in Google Chrome. Although Firefox also
> doesn't see the aria-label attribute, I was able to use all of the
> JAWS options that were problems for the other two browsers.
>
> Since our catalog is a 2.3 catalog, I did a bulk of my testing in http
> ://laurentian-test.concat.ca (thanks to Dan Scott for sharing the link
> to his test server!) and in http://sclends.lib.sc.us/ as both are 2.4
> systems using auto-suggest. As a contrast, I also conducted similar
> tests in the MVLC and Bibliomation catalogs, both of which are 2.4ish
> systems that have not enabled autosuggest. The MVLC and Bibliomation
> catalogs did not ...

Read more...

Dan Scott (denials) wrote :

And to add to the tools, a few months back I noted a few free tools recommended by Twitter's "accessibility guy", Jennison Asuncion, at the OLA SuperConference:

* NVDA: http://www.nvaccess.org/
* WebAnywhere: http://webanywhere.cs.washington.edu

(see https://plus.google.com/s/%23olasc14%20%23accessibility for the context)

Kathy Lussier (klussier) wrote :

Hi Bill,

I can take a quick look at it with JAWS and also send it along for testing by a more experienced JAWS user.

Thanks!
Kathy

Alex Lazar (alexey-lazar) wrote :

I think this problem statement and discussion are based on an assumption that this feature is actually useful for low- or non-vision users. To take a step back, let's say even if this feature would have been implemented in a screen-reader-compatible way, would it actually improve user experience for non-vision patrons? Or maybe it would only steal the focus to blast some more robotic verbiage adding another barrier and delay to getting through to the OPAC search results? That could be especially true if all the top auto-suggestions turn out to be bad guesses based on too few initial characters input.

I don't claim to know the answer and it likely varies based on personal preference within the target audience, but considering "faster to search with fewer clicks" as a measure of improvement when using web search forms, perhaps disabling this feature from non-visual browsers could be a quick[1] fix of this feature for non-vision users in the immediate term.

As far as the future of this or similar features for Evergreen OPAC, jQuery is probably unavoidable in some shape or form, but probably better to stick with something Angular/Bootstrap-integrated and not to have a whole lot of extra code-load or a whole separate library to maintain for just one feature. For example, there is a library called Select2 that does all kinds of cool stuff with select boxes and various form elements. It is "a jQuery based replacement for select boxes. It supports searching, remote data sets, and infinite scrolling of results" [2], [3]. Although, I do not know how it performs in JAWS or Windows-Eyes.

[1] I recall it used to be possible to hide using visibility: none and/or display: none, but at this point that would need some testing, as newer versions of screen readers may ignore those rules.
[2] http://ivaynberg.github.io/select2/
[3] https://github.com/ivaynberg/select2

Kathy Lussier (klussier) wrote :

As the person who submitted the original bug report, I want to clarify that there was no assumption that autosuggest would be useful to low- or non-vision users.

The problem is that one of our sites turned on autosuggest as a service to their vision users. They immediately began receiving complaints from non-vision users of JAWS who could no longer do a basic search of the catalog because JAWS is no longer able to recognize the text entry box. The user wasn't trying to use autosuggest, they were just trying to search.

Kathy Lussier (klussier) wrote :

Sorry, Alexey, I mised the comment further down about disabling for non-visual browsers.

The problem is that they aren't using non-visual browsers. They're using IE. JAWS is the screen reading program. My recollection from IRC discussions on this question was that you can't detect that JAWS is being used.

Rogan Hamby (rogan-hamby) wrote :
Download full text (6.0 KiB)

Correct, JAWS doesn't work as any kind of plugin or other service that the
browser will recognize.

On Thu, Jul 17, 2014 at 9:17 AM, Kathy Lussier <email address hidden>
wrote:

> Sorry, Alexey, I mised the comment further down about disabling for non-
> visual browsers.
>
> The problem is that they aren't using non-visual browsers. They're using
> IE. JAWS is the screen reading program. My recollection from IRC
> discussions on this question was that you can't detect that JAWS is
> being used.
>
> --
> You received this bug notification because you are subscribed to
> Evergreen.
> Matching subscriptions: evergreenbugs
> https://bugs.launchpad.net/bugs/1187993
>
> Title:
> Auto suggest causes significant accessibility issues for using basic
> search in some browsers
>
> Status in Evergreen - Open ILS:
> Confirmed
>
> Bug description:
> As was noted in a searchbar.tt2 comment from commit
> http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=aaf2d7f5f4ecd7dd36d5aee5ced23de78712ff62,
> autosuggest breaks accessibility, as the aria-label
> attribute is removed when the Dijit is created.
>
> We received a report from a patron that she is no longer able to
> conduct a search in the catalog when using the JAWS screen reading
> program. She previously had success searching the catalog a few months
> ago, and we traced it to the implementation of auto-suggest in the C/W
> MARS catalog.
>
> I don't know if the same problem occurs in other screen reading
> programs, and I personally don't have much experience with JAWS, but,
> in my own testing, I found that the accessibility problems makes it
> extremely difficult to conduct any kind of basic or searchbar search
> in IE and, to a lesser extent, in Google Chrome. Although Firefox also
> doesn't see the aria-label attribute, I was able to use all of the
> JAWS options that were problems for the other two browsers.
>
> Since our catalog is a 2.3 catalog, I did a bulk of my testing in http
> ://laurentian-test.concat.ca (thanks to Dan Scott for sharing the link
> to his test server!) and in http://sclends.lib.sc.us/ as both are 2.4
> systems using auto-suggest. As a contrast, I also conducted similar
> tests in the MVLC and Bibliomation catalogs, both of which are 2.4ish
> systems that have not enabled autosuggest. The MVLC and Bibliomation
> catalogs did not encounter any of the problems described below.
>
> Testing in IE 10:
> 1. When arriving to the catalog search page in IE10, the cursor often
> started in the text search box, but this didn't happen consistently. For
> example, when clicking the "Another Search" link to return to the home
> page, you were less likely to land in the search box. If the cursor
> immediately landed in the search box, then the JAWS user could easily type
> the search terms and conduct the search.
>
> However, if the cursor didn't land in the search box or if the user
> moved the cursor away from the search box, it's nearly impossible for
> the user to return to the search box without visual assistance as a
> result of the following two problems:
>
> 2. A JAWS user typically can use the "F" key as a s...

Read more...

Alex Lazar (alexey-lazar) wrote :

Thanks for clarifying my thinking on the issue.

I look at the search box code and see:

<span class='search_box_wrapper'>
<label id="search_box_label">Search:
<input type="text" id="search_box" name="query" aria-label="Enter search query:" value=""
                dojoType="openils.widget.AutoSuggest" type_selector="'qtype'"
                submitter="this.textbox.form.submit();"
                store_args='{"org_unit_getter": function() { return 1; }}' />
</label>
</span>

The auto-suggest <div> and the descendent <ul> an <li> items are inserted using dojo overlaying the regular search box.

Then using Firebug to look at the code dojo injects into the page, the wrapper <div> looks like:
<div id="widget_search_box_dropdown" class="dijitPopup" style="z-index:1000; visibility: visible; top 224.883px; left: 70.633px;" role="presentation">

With adding an attribute of aria-hidden="true" [1], in theory the screen reader should ignore the <div> and contents:
<div id="widget_search_box_dropdown" class="dijitPopup" style="z-index:1000; visibility: visible; top 224.883px; left: 70.633px;" role="presentation" aria-hidden="true">

Is this doable in dojo? Unfortunately, I don't have time right now to play around with it and have no immediate access to JAWS to test.

[1] http://www.456bereastreet.com/archive/201205/hiding_visible_content_from_screen_readers_with_aria-hidden/

Mike Rylander (mrylander) wrote :

You know ... it looks like it might be possible via this.domNode in the openils.widget.AutoSuggest module. It inherits its constructor, though, so I'm not sure where to hook that in, but postMixInProperties is a likely candidate. Anyone feel like attempting to use this patch?

diff --git a/Open-ILS/web/js/dojo/openils/widget/AutoSuggest.js b/Open-ILS/web/js/dojo/openils/widget/AutoSuggest.js
index 8192751..41ad846 100644
--- a/Open-ILS/web/js/dojo/openils/widget/AutoSuggest.js
+++ b/Open-ILS/web/js/dojo/openils/widget/AutoSuggest.js
@@ -134,6 +134,8 @@ if (!dojo._hasResource["openils.widget.AutoSuggest"]) {
             "postMixInProperties": function() {
                 this.inherited(arguments);

+ this.domNode.setAttribute('aria-hidden','true');
+
                 if (typeof this.submitter == "string")
                     this.submitter = dojo.hitch(this, this.submitter);

---------------------

My next attempt would be to move that new line down into postCreate.

We did a test of Mike's script here and I was getting it to read properly using Chrome Vox for the autosuggest.

Mike Rylander (mrylander) wrote :

Kathy mentioned in IRC that Chrome Vox doesn't seem to be a problem, but the test was important anyway, as it means that the new line of code didn't break anything obvious, in the least. Thanks, Tim!

Alex Lazar (alexey-lazar) wrote :

Tim, do you mean that with the addition of aria-hidden="true" attribute Chrome Vox ignored the auto-suggest contents, as was the intent of adding that attribute?

Kathy Lussier (klussier) wrote :

I finally had a chance to test the changes Mike suggested.

The good news is that after making the suggested change in AutoSuggest.js, JAWS seemed to behave better in IE. The bad news is that AutoSuggest stopped working altogether with that change.

I then moved the line down to postCreate as Mike suggested. AutoSuggest kept working, but then we started to see the same problems with JAWS that we previously saw. If I use the "E" key to go to the first edit box, JAWS tells me there is no edit box on the screen. If I use the "F" key to navigate through form elements, it only recognizes the dropdown form elements on the page, not the text entry box.

It's as if JAWS doesn't recognize that box as a text entry box (or even a form element) once AutoSuggest is enabled.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers