Auto suggest causes significant accessibility issues for using basic search in some browsers
As was noted in a searchbar.tt2 comment from commit http://
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://
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-
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:
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"
|Changed in evergreen:|
|status:||New → Confirmed|
|importance:||Undecided → High|
|Rogan Hamby (rogan-hamby) wrote : Re: [Bug 1187993] Re: Auto suggest causes significant accessibility issues for using basic search in some browsers||#13|