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
>
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- /bugs.launchpad .net/bugs/ 1187993 git.evergreen- ils.org/ ?p=Evergreen. git;a=commit; h=aaf2d7f5f4ecd 7dd36d5aee5ced2 3de78712ff62, test.concat. ca (thanks to Dan Scott for sharing the link sclends. lib.sc. us/ as both are 2.4 enabled catalog because JAWS /bugs.launchpad .net/evergreen/ +bug/1187993/ +subscriptions
> 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:/
>
> 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://
> 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-
> to his test server!) and in http://
> 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-
> 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:/
>