Contents
- About
-
Configuration
- How can I get LSR?
- What devices does LSR support?
- How can I get the IBM TTS engine?
- How can I get a different supported speech engine?
- How does LSR choose an output device?
- Do you support any Braille devices?
- Do you support a Magnifier device?
- How do I enable LSR at the login screen?
- How do I enable GNOME to run the screen reader on startup?
- Troubleshooting
- Contributing
- Miscellaneous
About
What is LSR?
The Linux Screen Reader (LSR) project is an open source effort to develop an extensible assistive technology for the GNOME desktop environment. The goal of the project is to create a reusable development platform for building alternative and supplemental user interfaces in support of people with diverse disabilities.
The original use of the LSR platform was to give people with visual impairments access to the GNOME desktop and its business applications (e.g. Firefox, OpenOffice, Eclipse) using speech, Braille, and screen magnification. The extensions packaged with the LSR core were intended to meet this end. Development on these extensions has ceased. However, the core of LSR might still serve its purpose as a platform in other creative endeavors, such as:
- Supporting novel input and output methods, such as joysticks, web cams, game pads, audio icons, and environmental sounds.
- Creating interfaces for other users, such as people with mobility impairments, people with cognitive impairments, children learning to use a screen reader, and so forth.
- Supplementing the graphical GNOME desktop with useful audio feedback for sighted users, such as text-to-speech reporting of events in a monitored window.
See our 14-minute screencast titled Linux Screen Reader ... is not just a screen reader for demonstration of LSR's extensibility.
Why Orca and LSR?
There are a number of non-competitive reasons for having two extensible assistive technologies for the Gnome desktop.
- Two implementations stress test desktop accessibility in non-overlapping ways.
- Two design philosophies explore different ideas for system architectures and user interfaces.
- Two products enable user choice based on the task at hand, personal preferences, and the individual strengths of the two systems.
There is ton of room for innovation in the field of enabling technology.
Configuration
How can I get LSR?
Follow the getting started directions for help on obtaining and installing LSR.
What devices does LSR support?
As of version 0.5.0, we have tested the IBM TTS, DECtalk, Clique Audio, Eloquence, Loquendo, Swift, Theta, Espeak, FreeTTS, and Festival speech engines for output and the standard keyboard for input. In addition, LSR supports Braille via the BRLTTY package for both input and output. Testing has only been performed on a simulator so we welcome any Braille device users who would like to test. Community contributions of code supporting new devices will be graciously accepted and attributed to the rightful authors. See the device developers page for assistance in supporting new devices.
How can I get the IBM TTS engine?
Visit Voxin to purchase IBM TTS plus pre-compiled drivers for i386. Alternatively, visit the TTSynth marketing page from Capital Accessibility, LLC.
=== What if I want to run IBM TTS under Ubuntu? ==
See this ticket for the steps to get ibmtts working with LSR under Ubuntu.
How can I get a different supported speech engine?
DECTalk: Visit the purchase page for the DECtalk runtime on the Fonix Corporation website.
How does LSR choose an output device?
When first run, LSR automatically uses any available output device just to get started. Once up and running, you can select your preferred device using the settings dialog (Alt-Shift-Q). See the user guide for details.
Do you support any Braille devices?
LSR supports Braille via the BRLTTY package. This package supports most major brands and LSR should work with all of them. See BRLTTY for more information.
Do you support a Magnifier device?
LSR supports the gnome-magnifier.
How do I enable LSR at the login screen?
See the instructions for accessible login.
How do I enable GNOME to run the screen reader on startup?
See the instructions for configuring your GNOME session.
Troubleshooting
Why does LSR segfault when it quits?
This is a bug in versions of pyorbit earlier than 2.14.1.
LSR won't install. What's wrong?
Follow the directions in the getting started guide. If you are still having trouble, post a message to the LSR mailing list at lsr-list@gnome.org asking for help. We will improve the installation guide as people encounter problems.
LSR starts, but I don't hear anything. What's wrong?
Try these steps to resolve the problem.
Make sure you have followed the directions on the getting started page.
Run lsr -y "this is a test" to have LSR speak a test string using the default audio device. If no speech is heard, you may not have a supported speech engine installed.
- Make sure you have enabled AT support on the desktop in the gnome-at-properties dialog. LSR should do this for you when you first run it, but you need to log out and log back in before the changes will take effect.
- Make sure the application you are trying to run supports accessibility. Some apps require the GTK_MODULES environment variable to be set to gail:atk-bridge before running.
- Run lsr and navigate to another window. No speech is currently given on the terminal window in which LSR started.
autogen.sh fails. What am I missing?
Make sure you have both the gnome-common and intltool packages installed on your system.
Contributing
How can I contribute?
There are a number of ways in which you can contribute to LSR:
- Use LSR. Everyday use is the best way to identify problems.
File bug reports. Use this template to report any errors encountered.
- File feature requests. Again, visit the LSR Bugzilla module to post requests for enhancements.
Share ideas. Post your thoughts about current and future uses of LSR on the mailing list at lsr-list@gnome.org.
Create extensions. View the device developer's guide and the script developer's guide for help in adding support for new devices, new kinds of tools for the user, and improved application usability.
Hack the core. Read the core developer's guide for help in contributing to the LSR architecture.
How do I add support for my speech or Braille device?
Most Braille devices should be supported via BRLTTY. For speech, check the section on speech for supported speech devices. If your device is not supported, start by reading the device developer's guide.
How do I write my own LSR scripts?
Start by reading the script developer's guide.
How can I improve the accessibility/usability of a particular application?
Start by reading the script developer's guide.
How can I support other user needs and abilities?
Extensions to LSR can serve practically any accessibility or usability purpose. The trick is knowing what users need and how LSR can help satisfy that need. Share your idea on the LSR mailing list at lsr-list@gnome.org and we'll try to get you off to a running start on your own, creative use for LSR.
What do you mean when you say LSR is extensible?
The architecture of LSR is such that the UI is kept separate from the code responsible for managing accessibility information on the current platform. A core set of components listens for accessibility events and delivers them to cascaded scripts. A script can respond to accessibility events, register and respond to keyboard commands, show and communicate with GUI dialogs, dynamically load and unload other scripts, and so on. All of this work is done by making simple method calls using an API we provide for script writers. Scripts, devices, and GUI dialogs are all extensions recognized and managed by the LSR core.
Here's why we think this design is interesting:
The scripting API is devoid of AT-SPI specific code. Therefore, scripts have no reference to AT-SPI and could conceivably run unchanged on any platform that LSR supports.
An adapter package abstracts all AT-SPI information to an internal set of methods and events which are used by the scripting API. If, for example, a new adapter package was created to bridge Apple's Universal Access API to the LSR interfaces, any existing LSR scripts could remain intact and function on OS X. (Of course, this assumes UA provides all of the features of AT-SPI. Still, we can easily support gracefully degradation.)
Scripts can be cascaded N layers deep for each application. For example, when a Gaim chat client is active, our screen reader experience might be formed from:
- our default script providing basic screen reading services,
- our Gaim script providing additional services specific to Gaim (e.g. announcing changes in idle, typing, unread conversation state),
- our developer script defining hotkeys for reporting debugging information (e.g. speak the names of all of the loaded scripts), and
- a (hypothetical) spell-check script which indicates misspelled words in the chat message text box.
All of these scripts work in concert and provide some aspect of the user interface.
The scripts, dialogs, and devices that comprise the screen reader interface exist in a "user" profile. The command line interface to LSR lets you construct a new profile containing a wholly different set of scripts, dialogs, and devices. For example, you could create a new profile named "osk" and add to it:
- a GUI dialog that shows an on-screen keyboard
- a script that loads for all applications and synthesizes keyboard events in response to button presses in the keyboard GUI dialog
- another script that dynamically adds buttons to the dialog based on the actions available in the current context (e.g. all menu items)
- other scripts that are written for specific applications and buttons for specific actions/macros
- an input device adapter supporting a head switch, no-touch web cam acting as a switch, etc.
Running under this profile has no effect on the other profiles. In other words, if the osk profile actually existed, LSR could be used both as an on-screen keyboard and a screen reader depending on what profile is active.
The GUI dialogs can be created using whatever toolkit you choose. Our screen reader dialogs are gtk because we're on GNOME. But nothing prevents a developer from creating Windows, Qt, XUL, etc. GUIs, adding them to a profile, and managing them with a script.
Miscellaneous
What is the LSR numbering scheme for versions higher than 0.5.0?
The version number of LSR follows the format major.minor.revision. The major number will reach 1 at some major milestone such as inclusion in GNOME or certification of certain aspects of LSR against pre-defined standards. Thereafter, it will increase when necessary when the minor version needs to increase above 9. The minor number represents whether the release is stable or unstable. Odd minor numbers indicate an unstable release. Even numbers indicate a stable release. The revision number corresponds with GNOME developer point releases. For instance, LSR unstable release 0.5.1 was released in correspondence with GNOME 2.19.1.