2003 Conference Proceedings

Go to previous article 
Go to next article 
Return to 2003 Table of Contents 


CUSTOMIZING THE JAWS BROWSER SCRIPT FOR WEB APPLICATIONS

Presenter
David Hoffman
IT Accessibility Specialist
MILVETS Systems Technology Inc.
Social Security Administration
Phone: 410-966-1839
Fax: 410-965-0914
Email: david.hoffman@ssa.gov

Subject: Customizing the JAWS Browser Script for Web Applications

Overview

The migration of business process software to web application architecture is creating new workplace accessibility challenges and opportunities. This paper examines the unique challenges and opportunities that web applications create for JAWS users and proposes various means of using the powerful JAWS scripting language to overcome these challenges -- without causing unintended side effects when using the browser for other purposes.

Introduction to the JAWS Virtual Cursor

Most software applications have a cursor that identifies the point of focus. JAWS refers to this focus as the PC cursor. The text within a web page, however, does not receive a focus. Therefore, in order to read the text within a web page, JAWS reformats the web page content into an invisible buffer. This buffer can be thought of as a read-only invisible text editor. JAWS then uses a "virtual cursor" to read from this buffer. This virtual cursor enables JAWS users to perform the basic web functionalities of navigating through text and selecting hyperlinks or buttons. In JAWS version 4.5x, the virtual cursor allows checkboxes and radiobuttons to be selected as well.

Introduction to HTML Forms

Web Applications generally use HTML (Hyper Text Markup Language) for displaying information and forms. HTML forms allow users to input information for transmission to a server. Popular examples of HTML forms include search engines, e-commerce order forms and web-based e-mail. HTML forms may contain various controls, including edit boxes, check boxes, radio buttons, combo boxes, list views, text areas, and buttons. While the default virtual cursor mode handles most basic and common web tasks, the virtual cursor by itself cannot be used to complete HTML forms that contain edit boxes, combo boxes, list views, or text areas.

Introduction to Forms Mode

Edit boxes, combo boxes, list views, and text areas require the use of an application cursor (the JAWS PC cursor). The virtual cursor, which is necessary for reading and navigating through the text on a web page, cannot directly manipulate these controls for inputting information. On the other hand, the PC cursor only has access to controls and links, not text. Therefore, the virtual cursor features a special "forms mode" to allow data input when otherwise using the virtual cursor. Forms mode is actually a specialized form of the PC cursor.

The Migration from Windows Clients to Web Architecture

There is a growing trend to use web forms to migrate existing software applications to web architecture. This architecture shift presents both an advantage to and a disadvantage for accessibility with JAWS. JAWS includes a powerful scripting language that is used to customize its functionality with specific applications. Windows applications generally rely heavily on custom JAWS scripting. The advantage of web applications is that they can generally be made accessible without custom scripting by using proper HTML. The disadvantage is that custom scripting for web applications is not recommended, even in situations where custom scripting could improve the accessible usability of the application.

Custom Scripting: Not Recommended for the Browser Script

JAWS scripters can create specific JAWS scripts for each windows client application. One application's script does not have any effect on any other application. However, all web-based information, forms, and applications share the same client -- the browser, as their user interface. Since they use the same windows client, they share the same JAWS browser script. Therefore, any modification to the browser script to address a specific situation, web site or application may cause unpredictable results when using the browser for other purposes. As a result, of this, as well as version management issues, custom scripting in the JAWS browser script is discouraged. Likewise, Freedom Scientific documentation does not include any information regarding custom scripting for the browser.

Custom Scripting: Not Necessary for the Browser Script

HTML development benefits from clear and specific accessibility requirements. As a result, Freedom Scientific has been able to improve JAWS to the point where one generic interface does a fairly good job of accessing any web site that follows accessibility guidelines. Contrast that achievement with windows client development. Windows development accessibility goals are clear, but the means are elusive. Every development environment introduces its own variations of windows controls. It is no wonder that screen readers have been unable to keep up. As a result, virtually every windows client application requires custom scripting. They are rarely accessible "out of the box". Even Freedom Scientific does not provide specific windows developer guidelines to enable JAWS accessibility without the need for custom scripting.

Web Applications: Is the Default Browser Script Adequate?

There are circumstances when custom scripting could significantly improve the JAWS usability of web applications. This is especially true of complex workplace business applications. Creative use of HTML as the display mechanism for these applications presents new challenges for JAWS. In addition, even if each individual control in an application is accessible, the application may remain cumbersome. The grouping of the controls and interaction between the pages may still cause accessibility problems. Navigation within the application may remain a significant challenge to JAWS users. In such circumstances, custom scripting application-specific versions of the JAWS browser script could improve the accessible usability of the application.

Task Analysis: The JAWS Browser Script is for Web Browsing

The JAWS browser script is optimizing for web browsing. The most basic and common web tasks are navigating through text and selecting hyperlinks or buttons. Therefore, whenever a web page is loaded, the JAWS virtual cursor is the default JAWS mode. The need to input information into a form control is the exception. Forms mode is used to address this exception situation. This is very appropriate. The common, basic functionality is handled by the default mode. Then, on occasions when input is required, the user must activate forms mode.

Task Analysis: Using the JAWS Browser Script for Web Applications

The JAWS browser script is not optimized for web applications. While web applications generally use the same user interface technologies as web sites, the tasks are very different. Web applications are generally form-centric. Text is primarily used to label the form controls or to provide supporting information. Forms are the rule and text is the exception. However, whenever a web page is loaded, the JAWS virtual cursor is the default. Prior to completing each new form page, a JAWS user must navigate to the first control and activate forms mode. If client-side scripting refreshes the page, the JAWS user must start again from the top of the page, and again navigate to the appropriate control and activate forms mode. In addition, web applications, like other applications, often require that specific tasks be performed in specific sequences, using specific parts of the user interface. The generic virtual cursor functionality may not provide reasonable support for such unique situations.

An Example of a Web Application Obstacle

Developers often use client side scripting to establish a PC focus on a particular control on a page. This enables non-JAWS users to immediately begin manipulating that control. As of JAWS 4.50, there is no keystroke for navigating the virtual cursor directly to such a PC focus. While JAWS users can use the CONTROL+INSERT+HOME keystroke to move the virtual cursor to the first non-link control on a page, they have no means of moving the virtual cursor directly to whichever control has the PC focus, regardless of its logical position on the page. The PC focus is likely to be located in a field other than the first non-link control on a form when non-link controls are located in header or navigation frames, or when the PC focus location on the form varies based on the circumstances. This is not a theoretical problem. It is a problem that I have seen in most of the complex web applications that I have reviewed.

Adding Features for Generic Web Applications

The most basic means of improving JAWS web application performance is by enhancing the generic functionality of the existing browser script. This enhanced functionality would ideally benefit many web applications and possibly other web resources. Freedom Scientific is beginning to respond to such web application issues in JAWS 4.51, as will be explained later in this paper. Ideally, future versions of JAWS will include enough generic enhancements to address most web application needs. However, even if they do so, significant time can pass until a need is identified, a feature is added, and the new version of JAWS is released, purchased, and in the case of the workplace, deployed by an employer. Therefore, certain browser script customizations, such as keystroke scripts, may provide significant benefits and minimal drawbacks, other than future version control issues.

Custom Keystroke Example

A script can be written to address the previously mentioned web application obstacle. A keystroke-activated script would route the virtual cursor to the PC cursor. While JAWS 4.50 does not include the ability to directly manipulate the virtual cursor in that way, the task can be accomplished indirectly, by writing a RouteVirtualToPC () script, as follows:

StopSpeech ()
SpeechOff ()
PerformScript VirtualPCCursorToggle()
PerformScript VirtualPCCursorToggle()
SpeechOn ()
PerformScript SayWindowPromptAndText ()

It must be emphasized that this solution is only a temporary workaround and has not yet been fully tested. But the solution does appear to work and it is the best option available as of the time of publication of this paper. This workaround may be utilized temporarily at a federal agency, at least until the agency tests and deploys JAWS 4.51, which, according to Freedom Scientific, will include this new generic web application feature: an INSERT+DELETE keystroke to RouteVirtualToPC. RouteVirtualToPC is only one of several web application related enhancements that Freedom Scientific is introducing in JAWS 4.51.

A Form-Centric JAWS Virtual Cursor

While enhanced web browser features will improve JAWS web application functionality, it will not change the fact that the virtual cursor is optimized for web browsing (as is appropriate). Therefore, it may be worthwhile to optimize an alternate generic browser script or web application mode for web applications. Such a generic script or mode for web applications might use a forms mode by default. JAWS could automatically find the PC focus, or if the PC focus were undefined, JAWS could find the first logical input control, and then turn forms mode on. JAWS could handle dynamic screen refreshes or updates without losing the current focus. The need to leave forms mode to read text that is not associated with a control would be the exception. Perhaps a means could be provided to address this exception without leaving forms mode. Such a means could involve either enhanced JAWS features or new HTML techniques. The ultimate goal would be to enable full application functionality without the need to switch between different modes. A JAWS browser script that is optimized for web applications might significantly improve the usability of JAWS with many web applications.

Application-Specific Custom Browser Scripts

In unique situations where enhancing the generic browser script is inadequate, it may be necessary to create application-specific browser scripts. However, unlike adding custom keystrokes to the default browser script, modifying the script events is problematic because of unpredictable results when using the browser script for other purposes. In fact, one vender delivered an "accessible" software solution to a government agency, complete with a customized JAWS browser script. The solution was truly accessible when used with the custom script, but other sites and applications no longer worked. The solution was rejected. Understandably, such modifications to the default browser script events are not recommended.

Switching Browser Scripts On The Fly

In order to implement either application-specific custom JAWS scripts and/or a generic form-centric web application script, without affecting the performance of the default browser script, it is necessary to at least allow a one-time modification to the default browser script. This modification would involve adding code to the JAWS event that executes each time a web page is loaded into the browser: the DocumentLoadedEvent() function. If the new page matches specific criteria, JAWS would switch to an alternate script using the SwitchToScriptFile() function. All application-specific scripting would occur in the individual web application versions of the JAWS browser script.

Determining Criteria for Different Scripts

An organization's application-specific custom JAWS scripts can be listed in a JAWS initialization file. Each time a web page loads, the code within the DocumentLoadedEvent() function would check the initialization file to determine if the page is part of one of the organization's web applications. If a match is found, the SwitchToScriptFile() function will switch to the application-specific custom JAWS script or to the generic web application script.

Perhaps even general Internet pages could be checked to determine if they are information-centric or form-centric. A formula could be used to compare the quantity of plain text to the quantity of input controls. JAWS would use the formula to "guess" whether to begin in forms mode or virtual cursor mode for that particular page. The user would need to have the ability to toggle between the scripts as well. A future WAI (Web Accessibility Initiative) guideline could even be used to identify forms to screen readers.

Conclusion

Web applications present new opportunities for and unique challenges to accessibility with JAWS. Clear and specific HTML accessibility guidelines provide the opportunity to strive for web software interfaces that work with JAWS, without the need for custom scripting. However, web applications also present unique challenges that cannot always be effectively handled by the default JAWS browser script. When appropriate, it is possible to selectively allow custom scripting for the browser in order to improve JAWS web application usability. Such application-specific scripting can even be accomplished without making application-specific changes to the default JAWS browser script. While these ideas require additional testing and analysis, it is clear that custom JAWS scripting for the browser can be an option for improving the accessible usability of some web applications.

David Hoffman
MILVETS Systems Technology, Inc.
Detail: SSA Baltimore
Location: 2-A-9 Operations
Phone: 410-966-1839


Go to previous article 
Go to next article 
Return to 2003 Table of Contents 
Return to Table of Proceedings


Reprinted with author(s) permission. Author(s) retain copyright.