Summary
Most of us have come across scenarios where web accessibility testing with assistive technologies produces unexpected results, when we know the underlying structure of the web page is correct. Assistive technologies are complex, so it's not surprising they sometimes go wrong, but we need to know how to recover when they're being unresponsive or providing incorrect information. My colleague, Hans Hillen, sent an email internally at TPG about handling erratic behaviour with JAWS, and has kindly allowed me to post it here, as this is useful information.
What techniques do you use to handle strange behaviour in JAWS and other assistive technologies?
Author: Gez Lemon
Dealing with JAWS Quirks
The following is the standard approach to dealing with JAWS Quirks (follow in order until the issue is fixed):
- Use Ins + Esc to refresh the virtual buffer. This sometimes causes JAWS to properly trigger virtual mode.
- Alt + Tab to a different application and then back to the browser. This sometimes causes JAWS to properly trigger virtual mode.
- Restart the browser. Specifically with Firefox, JAWS support is better if JAWS is already running when Firefox starts up. There was a time where this was required for Firefox to expose accessibility information, but this doesn't always seem to be the case anymore. Even so, in some cases this will fix the issue.
- Restart JAWS. Sometimes JAWS just needs to be restarted for it to behave properly.
Virtual mode stops working
The virtual mode has stopped working when the keystrokes to navigate the virtual buffer have stopped working. For example, H for heading navigation doesn't work anymore. When requesting a virtual list (e.g. a link list), JAWS will announce, "this feature is only available in a virtual document". The website is essentially being navigated in forms/application mode, although JAWS seems to provide less information than usual. When pressing certain virtual navigation keys, JAWS will be quiet, but if you press tab it will announce the keys as if you had typed them into a document (e.g. "H H H"). When tabbing between elements, JAWS may just say "TAB" or it may announce the focused element. Using the arrow keys will scroll the page rather than navigate virtually.
Virtual mode solutions
- Ensure that focus has been moved into the actual web page. If your focus is elsewhere in the browser, such as on the address bar, JAWS will consider it a desktop application that does not support virtual mode. Moving focus into the page should fix this (for example, by tabbing, clicking on the page with the mouse, or using the Ctrl + F6 shortcut).
- Use the standard approach for dealing with JAWS quirks.
Jaws announces the same element when tabbing through the page
Sometimes JAWS gets stuck on a particular element and it will keep announcing it, instead of the elements actually being focused. If you test with an accessibility inspection tool, such as aViewer or Inspect32, the browser does in fact expose the correct information for the focused element, but JAWS still announces something else.
Same element solutions
- Press INS + Tab. This causes JAWS to announce the focused element again, and sometimes this causes the currently focused element to be announced correctly.
- Turn off virtual mode using INS + Z (repeat twice to make the switch stick). This issue seems to be most common when tabbing between elements while virtual mode is active. It seems to increase specifically for elements that trigger auto forms mode. Manually switching to forms mode or application mode causes JAWS to announce the actual exposed accessibility information.
- Use the standard approach for dealing with JAWS quirks.
Broken table navigation
When navigating a data table (Ctrl + Alt + Arrow Keys), JAWS will sometimes act like there are no cells in a row or column. When navigating to an adjacent cell, it will announce "beginning/end of row/column", as though the actual cells in the data table do not exist.
Broken data table solutions
- Use the standard approach for dealing with JAWS quirks.
JAWS can't find elements
When navigating to tables, headings, lists, and so on, JAWS announces that there are no elements of this type on the page, even though there clearly are.
Missing element solutions
- Use Ins + Esc to refresh the virtual buffer, sometimes this cases JAWS to properly trigger virtual mode.
- Move (virtual) focus to the start of the page using Ctrl + Home. Sometimes JAWS seems to perform a shortcut within a specific scope, which is not always the actual page loaded in the browser. For example, if (virtual) focus is placed near the start of the document, the M key will list all frames in the loaded page. If you move inside one of those frames though, JAWS will only look inside that frame and it's not possible to find the other frames in the main document (until you move focus back to that scope).
Opening virtual HTML Features list
When using the INS + F3 shortcut for opening the Virtual HTML features list, JAWS will sometimes display the "JAWS virtual find" search dialog instead.
Virtual HTML features list solutions
- This also seems to be caused by the scope JAWS is currently in. It seems the (virtual) focus really needs to be inside the web content before you can use INS + F3 for the virtual HTML Features list. Anywhere else, and you get the Virtual Find dialog.
Other techniques
The intention of this article is to gather other recovery techniques for all assistive technologies. What techniques do you use to handle strange behaviour in JAWS and other assistive technologies?
Category: Accessibility.
[handling-erratic-behaviour-at.php#comment1]
Also, not too scarcely, I had to restart my computer. Only way to have Jaws come back to proper behaviour (Jaws 10 on Win XP, I must say; I haven't used Jaws so much since then, testing Jaws 13 these days)
Posted by Stephane Deschamps on
[handling-erratic-behaviour-at.php#comment2]
Never use the Nightly version of Firefox to test your latest and the greatest feature. You will get nothing but grief if you try. If JAWS gets stuck in focus mode and insert+z fails to bring up virtual buffer consistently across all pages, restarting JAWS as well as the Browser will fix the issue. If you have already restarted JAWS several times and not rebooted your system, JAWS will fail to load. Restarting Windows will fix this problem.
Posted by Pratik Patel on
[handling-erratic-behaviour-at.php#comment3]
Please use Jaws with Firefox for testing ARIA implementation for better results as Jaws tends to behave erratically with IE while testing for ARIA.
Posted by Priti Rohra on
[handling-erratic-behaviour-at.php#comment4]
This isn't specifically a Jaws issue, but in IE, Jaws stops working because IE gets hung up. You have to close the IE window by hitting alt plus c. Then the window closes and speech returns most of the time. Simply reopening the IE page will result in the problem returning, so you have to close all IE windows and start again or use FF instead.
Posted by Johnny Gee on
[handling-erratic-behaviour-at.php#comment5]
I have a machine running Windows 7 and IE8, the focus is not tracking properly, so that I can't reliably click on a link spoken by JAWS 13, adjacent links being activated instead. On the Win7 machine, dropping back to JAWS 12 cures the problem.
Posted by Mike Johnson on
[handling-erratic-behaviour-at.php#comment6]
When Jaws thinks it's in application mode rather than the virtual mode you know it should be in, try using Ins+Z to switch virtual mode back on.
Posted by Lynn Holdsworth on
[handling-erratic-behaviour-at.php#comment7]
I work for a community college and during a project involving complex images, it was discovered that JAWS users accessing long description files in IE will return a 404 or "page not found" error. This occurs when description files are using relative URL paths. To get around this, the full path (i.e. absolute URL) must point to the description file.
Long-description path examples:
Absolute URL
Relative URL
Tested with JAWS 14 - 16, and IE 9 - 11 in Windows 7 and Windows 8.x.
Posted by RL on