Comment 16 for bug 1187993

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