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
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,
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 users
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