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 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"
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/evergreen/+bug/1187993/+subscriptions
>