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

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.

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).

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.

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.

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*!)

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.

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.

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.

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.

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.

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...

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.

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 ...

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)

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

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

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.

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.

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...

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/

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.

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!

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?

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.

The WAI-ARIA Authoring Pattern for a combobox might help us think through exactly what behavior would be most helpful: https://www.w3.org/TR/wai-aria-practices-1.1/#combobox

For what it's worth, their "combobox with grid popup" example seems pretty similar to the current autosuggest implementation: https://www.w3.org/TR/wai-aria-practices-1.1/examples/combobox/aria1.1pattern/grid-combo.html#ex_label

Also adding the needsdiscussion tag, because it seems like we should get some consensus on the user experience we want for this autosuggest.

A good presentation on accessible autocomplete: https://www.youtube.com/watch?v=_w6KvvN9cWw

I know this bug talks about how autosuggest breaks the whole functionality of this form for screen reader users. But here's another article with some good tips about how to make the autosuggest itself more accessible.

https://adamsilver.io/articles/building-an-accessible-autocomplete-control/

I have been informed that Auto Suggest also causes a visual display issue in the BooPAC. Screenshot attached.

Would like to see the accessibility and the display issue fixed.

Kathy's original report (the aria-label disappearing) is still occurring, but it doesn't result in the same problems due to Bill's work on bug 1268636, which adds a label tag that continues to provide an accessible label after the aria-label disappears.

The autosuggest still has significant accessibility problems itself. I've claimed this bug to take a look at an accessible implementation without dojo.

Here is a branch with a new autosuggest: user/sandbergja/lp1187993-accessible-autocomplete

Here is the link: https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/sandbergja/lp1187993-accessible-autocomplete

Here are a few ideas for doing qa on this:

* Use a screen reader to interact with the autosuggest. The expected behavior is that once you start typing, you receive instructions saying that the down arrow will give autocomplete options. When you select an option with the arrow keys, it should announce the suggestion and its field class. Enter will accept a suggestion. Note that there is a bug with Safari + VoiceOver that is affecting this; hopefully other browser+screen reader combos work.

* Use a mouse and keyboard together to interact with the autosuggest.

* Run the test suite: cd $EVERGREEN_REPO/Open-ILS/web/opac/deps && npm i && npm run test

* Run the linter: cd $EVERGREEN_REPO/Open-ILS/web/opac/deps && npm i && npm run lint

Looking forward to hearing what you think!

Oooh, one other point. When setting this up for testing, make sure to follow Mike's guidance here: https://bugs.launchpad.net/evergreen/+bug/1917084/comments/2

Upon some preliminary testing:

- The test suite doesn't work with the version of NodeJS that Evergreen ships (namely, v16.17.1). Node doesn't get Fetch API support until at least 17.5. I'm going to start a thread on the developers list about bumping up the version of Node across the board.
- By default, Apache doesn't seem to know what MIME type to apply to mjs files. I needed to add "AddType test/javascript .mjs" to eg_vhost.conf

When testing using Narrator on Windows 10

- The "Press down arrow for autocomplete" instructions weren't read to me
- Using the down arrow to navigate through the selections didn't work correctly. The first down arrow press selected the first suggestion, but subsequent ones advanced Narrator's scan and reading, but did not actually select the subsequent suggestions so that they could be acted upon.

Also, per https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Modules#aside_%E2%80%94_.mjs_versus_.js, I think that we should consider either using the .js extension rather than .mjs or setting it to .js during a build step.

Reason: while editing the Apache config to add an AddType definition is not a huge deal, it might be just a bit too much of a friction point for an improvement that ideally would be backported down to the maintenance branches.

Oh, I should note that when Narrator is off that the arrow keys are behaving as I would expect.

Thanks for your testing, Galen. I've rebased and pushed several commits:
* A commit avoiding the use of the .mjs extension.
* Seeing no objections on the mailing list, and since node 16.x reached end of life last month anyway, a commit to use Node 18.
* A commit to fix some cases where clicking on an autocomplete option did not work

I can confirm the scan mode issue that Galen identified with Narrator in both Windows 10 and 11. Noting that this issue also affects gov.uk's accessible autocomplete, which was one of my inspirations while creating this patch.

If folks have any ideas about how to fix the Narrator issue, I'd gladly do so. If not, though, I'd propose not blocking this pullrequest over the Narrator issue. NVDA and VoiceOver are both working as expected for me, and both are used much more widely than Narrator per WebAIM's most recent survey (https://webaim.org/projects/screenreadersurvey9/).