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