JavaScript event tests part 1: mouseover

Friday, 21st July 2006

Author: Steven Faulkner

Contents

• Introduction
• Claimed Support for mouseover
• JAWS
• Window-Eyes
• Supernova
• The Tests
• Test Conditions
• VoiceOver
• References

Introduction

A Screen Reader is a non-visual user interface for supported operating systems and applications. Whilst screen readers support many popular applications, screen readers do not support all applications. When an application isn't supported, the functionality is limited, and in extreme cases, cannot be used at all with a screen reader. JAWS has its own scripting language to enable support for applications, and the programming community offers JAWS scripts to work with other applications.

Until recently the only web browsing application that had practical support by the screen readers discussed in this article was Internet Explorer (and other applications that used the Internet Explorer engine to display HTML documents). The latest versions of JAWS and Window-Eyes include support for the Firefox browser, although JAWS support for Firefox is still limited compared to its support for Internet Explorer. Supernova supports Internet Explorer, and does not claim to support Firefox. From adhoc testing, it appears that Firefox can be used successfully with Supernova, although it is not as fully supported as Internet Explorer.

Screen reader support for browsing HTML documents in supported applications is achieved through a virtual buffer. For a detailed explanation of screen reader modes, see making Ajax work with screen readers. The virtual buffer facilitates much of the advanced functionality for navigating and providing access to content in HTML documents; heading navigation, table header & data interrogation, link and form control lists, expansions of abbreviations, and much more.

[Back to the contents]

Claimed Support for mouseover

JAWS has claimed support for the mouseover event since version 5.0; Supernova and Window-Eyes have never claimed support for the mouseover event.

[Back to the contents]

JAWS

JAWS support for the mouseover event is unbelievably crass — it depends entirely on identifying the mouseover attribute inline in the markup. If it finds an element with an mouseover attribute it will announce its presence to the user when the element with the attribute has virtual focus. If a user activates the mouseover event using the appropriate key combination, JAWS will inform the user if the activation has resulted in a change in content that JAWS could detect, and provide the location (line number) of where change occurred. The user can then use the Jump to line function to move the virtual focus to that location in the document. JAWS also has functionality (accessed via the HTML options dialog) that announces string literals within JavaScript code that are triggered by the mouseover event. From the following comments in the JAWS script file containing the functions that enable this mechanism, it can be concluded that the mechanism by which JAWS accesses a string literal is rudimentary to say the least:

OnMouseOver attributes are often used to run script functions to display tooltips containing useful information. If no OnMouseOver quoted text is found, JAWS speaks the on screen text for the link. "OnMouseOver quoted text" is text provided through a function in the OnMouseOver HTML attribute, in the form of: OnMouseOver="myfunction('information about link')". If more complex script code is referenced in the OnMouseOver attribute, the information is ignored.

Source: text comment in the JAWS 'Configuration Manager.jsb' file

JAWS mouseover conclusions

• JAWS announces the presence of inline onmouseover attributes on elements. The user can activate the event by using the Ctrl+Insert+Enter keystroke combination when the virtual focus is on the element that has the event attached.
• Its support (that is its identification and announcing of mouseover events) is based on it identifying the onmouseover attribute inline within the markup.
• Whilst JAWS doesn't announce the presence of mouseover events that aren't written inline, they can be activated using the keystroke combination, Ctrl+Insert+Enter. Of course, this is of little practical use, as the user isn't aware the mouseover event exists.
• The event is simulated by causing the mouse cursor to physically move to the coordinates on the screen corresponding to the position of the element within the document. The coordinates used are those that JAWS has stored in its virtual buffer.
• Using the Ctrl+Insert+Enter keystroke combination on an element with an onmouseover attribute identified by JAWS, triggers a refresh of the virtual buffer. JAWS then compares the new version with the previous version of the document. If JAWS finds changes within the content of the document it announces the change; otherwise, it announces, could not detect change in content.
• If a delay (> 500 milliseconds) is placed on the processing of the script triggered by the mouseover event, the addition of the new content to the document in the web browser occurs after the "virtual buffer" has been refreshed. In this case JAWS announces that it could not detect change in content. This results in a disconnect between the content that is presented to the screen reader user and the content displayed in the web browser.
• If new content causes a change in the position of elements, but the new content is added following a delay, the virtual buffer will not contain the additional content, and element coordinates and other information available to JAWS from the virtual buffer will be outdated. If the mouseover event is triggered a second time, JAWS moves the mouse cursor to the position in the document (in the web browser) using the outdated coordinates. Depending on the circumstances, the following might occur:
  • an incorrect event being triggered
  • a correct event on a different element being triggered
  • or no event being triggered (if the outdated coordinates position the mouse cursor over an element with no attached events).
  But it also results in JAWS announcing that a change in content has occurred: The change identified by JAWS is the content added due to the original triggering of the event, which was not identified by JAWS initially, because it occurred after the virtual buffer was refreshed.

[Back to the contents]

Window-Eyes

Window-Eyes does not claim to support the mouseover event, and the test results reflect this. If perchance the user knows that a mouseover event is attached to a particular element within a document and the user moves the virtual focus to that element, the mouseover event can be triggered by using the Window-Eyes Mouse hot-key: Mouse to focus Insert + Numpad-Plus, which results in the mouse cursor moving over the element with the attached mouseover event, but there is little practical value as the user is not informed of the presence of the mouseover attribute.

• Activating the mouseover (using the mouse to focus hot key) does not result in the virtual buffer being refreshed.
• Tests incorporating a delay and a change in element position do not result in the element coordinates being outdated.

[Back to the contents]

Supernova

While Supernova does not claim to support the mouseover event and does not inform the user that an element has this event attached, the event can be triggered by the pressing of the Enter key when an element has virtual focus. This is due to the mechanism by which Supernova passes keystroke commands to the web browser. Unlike JAWS and Window-Eyes, the mouse cursor is moved to the location of the element that has virtual focus whenever the Enter key is pressed. It appears that this method is used by Supernova to activate links. There is little practical value, as the user is not informed of the presence of the mouseover event, but the additional content is available to the user once added.

[Back to the contents]

The Tests

The tests consist of documents containing either an anchor (a element) or a paragraph (p element) with an inline onmouseover attribute that activates a JavaScript function. The function either adds text content to the element containing the event or to another element prior to the element containing the event. The latter results in the position of the element containing the event being changed by the addition of new content.

Each test has two conditions:

1. the function is processed immediately
2. the function is processed after a delay of 1500 milliseconds.

The reason for the second condition is that there is a delay between when an event is triggered by some screen readers and the triggering of the refresh of the document copy that is stored in the virtual buffer. For JAWS, the delay is approximately 500 milliseconds; for Window-Eyes, the delay is approximately 900 milliseconds. The delay, if there is one, for Supernova could not be ascertained. So the delay condition was included to investigate the issues that arise from content changes that occur after a user event caused the virtual buffer to be refreshed.

[Back to the contents]

Test Conditions

All test were conducted using Internet Explorer 6.0, JAWS v7.1 beta, Window-Eyes 5.5, and Supernova 6.51. The default mode of the screen readers was used for the tests (JAWS — Virtual PC Cursor; Window-eyes — Browse mode; Supernova — Virtual focus).

[Back to the contents]

[Back to the contents]

[Back to the contents]

[Back to the contents]

[Back to the contents]

[Back to the contents]

[Back to the contents]

[Back to the contents]

VoiceOver

The Mac OS X Tiger has "built-in" screen reading software called VoiceOver. When it comes to accessing HTML documents, an initial assessment from an article on VoiceOver published by the (U.S.) National Federation of the Blind concludes:

VoiceOver, in its current technical state, lacks the sophistication and maturity to be capable of allowing efficient Internet Browsing by blind users.

Roger Johansson has a more positive opinion of VoiceOver. Roger states, It doesn't have all the features of a more advanced screen reader like JAWS, but from the testing I have done so far it seems to do a decent job., but points out that he is, by no means as experienced with screen readers as someone using one on a daily basis.

VoiceOver mouseover test results

Alastair Campbell has kindly provided his results using VoiceOver.

• Whether it's a link or just text, there is no indication that there is a mouseover event to trigger.
• There is no assigned keyboard command to activate onmouseover.
• However, if you knew there was something to activate, you can make the mouse pointer go to the current keyboard cursor position with, "Move VO to mouse" (Ctrl+Option+Cmd+F5), which will activate the mouseover event.
• If the mouse pointer is set to follow the keyboard cursor "Mouse cursor tracks VoiceOver cursor", tabbing through the content causes the mouse pointer to move with the keyboard cursor. In this case, the mouseover event will fire on elements that have a mouseover event attached as you move through the content.
• Activating "Move VO to mouse" on a link results in the cursor moving to the top of the screen.
• Activating "Move VO to mouse" on text results in the cursor remaining over the text.
• With the non-link events, moving focus away from the text and back again results in the new text (content) being available to the user.
• On test 7, the cursor is left in the same place as the new text, but if you query the current item, it reads out the former text.

Alastair also posted a request for feedback on the macvisionaries mailing list, which elicited testing results from other users.

[Back to the contents]

References

• JAWS Documentation
• Window-Eyes 5.5 Manual (PDF)
• Supernova Tutorials
• OnMouseOvers and JAWS
• VoiceOver help
• VoiceOver keyboard commmands [PDF, 400kb]

[Back to the contents]

Category: Accessibility.