2006 Conference General Sessions

TWO DIFFERENT APPROACHES TO MAKING THE GNOME DESKTOP REMOTELY ACCESSIBLE

 

 

Presenter(s)
Sina Bahram
North Carolina State University
312 Montibello Drive
Cary NC 27513
Day Phone: (919) 345-3832
Email: sbahram@ncsu.edu

Presenter #2
Peter Korn
Sun Microsystems
4200 Network Circle

Santa Clara CA 95054

Email: peter.korn@sun.com

A report on NC State's efforts to deliver campus-wide remote-access accessibility.  Two solutions with UNIX/Linux and GNOME: text on the client & Media Application Server.

Background
In August 2004, North Carolina State University's College of Engineering and (ITD) Information Technology Division's High Performance and Grid Computing services launched a Virtual Computing Lab (VCL) pilot project (http://vcl.ncsu.edu). Based on high-end IBM Blades server technology, the VCL is intended to test the feasibility of developing new remote access services to provide students in engineering and computational science courses high-end software and computing resources. Ideally, the VCL will provide qualified campus and distance education students with "universal" access to these resources - in other words, access anywhere, anytime, and for anyone.

The good news is that in keeping with best practices, accessibility for students and faculty using assistive technologies was incorporated into the design parameters in the early stages of this "next generation" IT environment project. In part, this was due to 1) Web and IT accessibility education efforts on the NC State campus and elsewhere, 2) the growing awareness of technology accessibility as necessary to promote the national priorities of equitable access to education and employment opportunities, and 3) the legal obligations of a state funded research university. Another key factor was that HPC and Grid Computing services are part of the Information Technology Division (ITD). ITD supports campus-wide academic computing and has an Accessible IT Initiative committed to providing proactive and systemic approaches to achieving an inclusive and accessible NC State IT environment.

In addition to these value-driven and legal motivations for incorporating accessibility into the early planning for the VCL, there are other pragmatic strategic and economic benefits to this approach.

Scalable solutions to provide direct access to the virtual environment for people using assistive technologies would serve the diverse DE student population, serve advanced (and aging) researchers, simplify IT support, compared to physical labs Potentially scale to improve accessibility of next generation cyber infrastructure and grid computing applications

Phase 2:
In March of 2005, NC State presented at the CSUN conference on the successful accomplishment of phase 1, accessibility goals and initiatives for Windows blades on the VCL. For the second phase, NC State has been concentrating on the accessibility goals and initiatives on getting unix/linux blades accessible on the VCL.

One of our main goals has been the successful delivery of an accessible image containing the GNOME desktop environment running Gnoppernicus, the assistive technology that comes with GNOME. Gnoppernicus communicates to the user using a speech server in our initial testing this server was Festival. If one wishes to perform this behavior over a network connection, it becomes infeasible due to lag. If sound will need to be piped over the network using traditional tools such as Gnome's default sound manager or ESD (the Enlightenment Sound Daemon), then the delay, the buffer length, and other factors make an interactive accessible experience, all but impossible.

The importance of delay is an important issue to understand because it translates into the fact that a user will interact with the system via hitting some keys, using an accessible input device, possibly using voice, etc. The user will then wait for the sound to return back to the client that they are using, at which time the second issue of buffer length makes stopping the sound almost useless due to the fact that it is playing audio that was directly piped to the client. This audio could potentially contain more than one message; for example, it could possibly announce a new window having focus, as well as a different message about the elements of such a window, yet by stopping the pre-buffered audio that is sent over the network, one has no granular control over what is heard or not heard. Delay also translates into an immense drop in the productivity of a user, as well as the access, or lack there of, that such a user has. Since the primary medium for an audio based access solution to a computer is sound, and since delay is such a big problem because it is the only medium by which the user can obtain useful information, lag must be minimized to a completely unnoticeable level for a system to be remotely accessible via audio feedback mechanisms such as a screen reader like Gnoppernicus.

MAS allows one to have a network transparent layer through which sound can be sent to the user. This, at first glance, may appear not to be any better than ESD or GNOME's default sound manager; however, the differences lie in the implementation of how MAS transfers sound over the network. There are already products that use MAS with delays of only 100 milliseconds, compared to ESD's 3 seconds. At very high word per minute rates, which most screen reader user’s use, 100 milliseconds granular control is an amazing improvement over 3 full seconds of buffered sound. The following, from the MAS website (http://www.mediaapplicationserver.net) illustrates this concept.

Many of the visually impaired have finely tuned auditory sensibilities, allowing them to react quickly to sound. From its beginning, MAS was designed to handle timing issues exceedingly well. It was optimized to provide tight synchronization of multiple media
streams. More importantly, for users dependent on audio cues, it is designed to stop some functions and start others quickly. For example, a user, hearing the opening syllables of a menu option, can either select it or move to another option without waiting
for a complete articulation of the option. MAS's original accessibility requirements developed with leading accessibility authorities, included:

• Ability to stop utterances quickly
• Controllable low latency
• Format independent media handling
• High audio quality
• Multiplexing--with priorities
• Small memory footprint
• Synchronization of multiple media stream

Approach for implementation:
NC State will carry out the following test scenarios.
Have a Solaris image running the GNOME desktop, and use MAS to serve the sound.
Use windows, Linux, and UNIX to try to access this image and use GNOME remotely.

Have a Linux image (either Fedora Core 4 or Gentoo) running the GNOME desktop and serve the sound with MAS.
Use windows, Linux, and UNIX to try to access this image and use GNOME remotely.

If these tests succeed, then NC State will make images for our VCL blades so that all students, staff, and faculty may have access to Linux and UNIX images. By doing so, the VCL will then be able to successfully offer accessible Linux, UNIX, and windows images to its users.

Another approach:
Rather than piping the sound over the network, NC State wishes to attempt to act as a speech server to gnoppernicus. By doing so, we will receive all messages that are meant to be spoken, and then attempt to send these messages, as text, over the network to a client. The client can be something as simple as direct calls made to Microsoft's SAPI for speech output, a high quality speech synthesizer of the client's choice on any arbitrary operating system, and so forth. If possible, we wish to write this client in java as to offer platform independent clients to a hopefully platform independent server side solution.

Presentation:
Sina Bahram and Peter Korn will discuss the two different methodologies for making the GNOME desktop remotely accessible to users using assistive technologies such as screen readers. The presentation will highlight the solutions we found to problems that arose during the testing and implementation of the use of media application server to achieve remote accessibility to the GNOME desktop, as well as a discussion of the use of an alternative speech server, as discussed above.


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


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