I've moved lots of older content from around the wiki to this page. Some of it may still be useful, but as it was it was causing clutter and confusion.

  • Ubuntu Ubuntu Ubuntu Ubuntu Ubuntu Ubuntu Ubuntu Ubuntu Ubuntu Ubuntu Ubuntu Ubuntu Ubuntu Ubuntu

UDU Roadmap

Implementation Plan

(from the UDU Accessibility Roadmap Spec) See also: AccessibilityRoadmapDetails

  • Make sure that the available FOSS accessibility tools install and work on Ubuntu
    • Includes GOK, Gnopernicus, AccessX, Festival, Dasher, etc.
  • Make it easy to learn about, find, install and configure these tools
    • Make the packages available in the ship seed
    • Make the installer access-aware (On this page or this page of the installer we could put a 'Press F5 for accessibility features' notice at the bottom of the screen)

    • Support non-standard input devices such as speech hardware and serial mice.
  • Technologies that have been tested in Luke's Live derivative should be brought into the main branch

    • Certain packages should be included in the ship seed at least and be made an option in the installer (things like AccessX are a few KB and can make all the difference).

Packages Affected

User Interface Requirements

In general, user interface requirements are very diverse. No user will require all of these features; some are mutually exclusive.

  • Blind and visibility-impaired people
    • Text-to-Speech on the console
    • Text-to-Speech within X
    • Screen magnifier
    • Contrast-enhanced or contrast-reduced GUI colors
  • Deaf and hearing-impaired people
    • Make sure that all user interface sounds are accompanied by visible counterparts
    • Speech-to-Text
  • Paralyzed and mobility-impaired people
    • Support alternate input methods (e.g. single-dimensional pointers, eye tracking)
    • Make existing interfaces more error-tolerant (slow keys / pointer)

Outstanding Issues

We need to

  • compile a detailed list of affected packages
  • document how intrusive the changes are
  • determine how much of the work already done is appropriate for Breezy
  • find out what's missing to support a reasonably complete set of accessibility features, given that the needs of our users are very diverse -- we may not be able to meet all of them satisfactorily.

Detailed Comments

by LukeYelavich

This page examines the implementation plan for the Accessibility Roadmap discussed at the Ubuntu Down Under conference, and goes into some detail as to the work that needs to be done, from a vision impaired point of view.

Make the installer access-aware (On this page or this page of the installer we could put a 'Press F5 for accessibility features' notice at the bottom of the screen)

Apple have done this with OS X 10.4's installer. Their new screen reader, VoiceOver can be activated from the installer, however there is no such notice on the first install screen. Even then, since its intended use is blind and vision impaired users, how do they know when to press the key to enable accessibility? This could be resolved in a couple of ways:

  • Make the computer sound a beep to notify of when such a keystroke can be pressed. For low vision users, make something visually catching or the text for the accessibility keystroke very large to get one's attention.
  • Have the accessibility features on by default, but give the chance to able bodied users to turn accessibility features off.

Support non-standard input devices such as speech hardware and serial mice.

Serial mice would be quite easy. It is speech hardware that presents a very big problem. There are several screen readers available for Linux, for both text and graphical environments. However, not one single screen reader supports the same speech synthesizers. So in the case of Speakup, it supports a lot of hardware speech synthesizers, and software speech, whereas Gnopernicus via Gnome-Speech only supports software speech synthesizers, and no hardware devices.

If consistency was desired between GNOME and the console, either some hardware speech drivers, or software speech drivers would have to be ported to the other environment. Speakup is lucky that it supports software speech via a userspace daemon called speech-dispatcher, which is in Universe. Speech-dispatcher itself supports some hardware devices, but not nearly as many as speakup. What would make porting a little more difficult, is that the speech drivers for Speakup are kernel code. Even more problematic, is that they do not use the kernel's serial layer to communicate. They directly access the ports for the serial devices to allow the synthesizer to be accessed as soon as the kernel boots.

There is also Braille devices to consider. Luckily, the one package is used for the Braille back-end for both Gnopernicus and for the console. This package is known as BrlTTY, and allows Braille display access for the console, and provides an API for use in other applications, such as Gnopernicus to send data to the Braille display connected to the system.

Technologies that have been tested in Luke's AccessibleHoaryLiveCDDerivative should be brought into the main branch

Bringing the packages used in the Live CD into main shouldn't be hard, but if accessibility by default is desired, they need to be more tightly integrated with GNOME, for example making GDM accessible, using esd/PolypAudio to mix speech output with other system sounds, etc.

Certain packages should be included in the ship seed at least and be made an option in the installer (things like AccessX are a few KB and can make all the difference).

If accessibility is turned on in the install, accessibility should be turned on in the installed system, and the user choose what accessibility features they wish to use.

The AccessibleHoaryLiveCDDerivative page mentions a number of other packages which have already been modified.

Of particular note is the Sun modified Mozilla package. The accessibility patches that are included from Sun have largely not made it into the main Mozilla trunk, so perhaps these patches could be included with FireFox to make it more accessible, rather than ship another browser just for accessibility.

For blind/vision impaired use, there is still a lot of work that needs to be done to provide a consistent and usable interface to both GNOME and the console. Speech access for both environments is a particularly big problem, as outlined above. OpenOffice does work with the Java Access Bridge, but this naturally requires Java which is not currently shipped with Ubuntu, but that could change for Breezy. Another option is the a11y integration being worked on to use the Corba interface, rather than Java. This is still in its infancy however.


Some of these things probably belong in Accessibility/Ideas. If so, please fish them out Smile :)

Development Goals

Accessibility Wishlist

List anything here that would be a nice to have, but doesn't look like happening in the future, due to necessary outside participation, etc:

  • UnifiedSpeechSynthesisAPI

  • Hearing and Speech Impairments (Kevin Cole)

    • Computer accessability often looks at vision-impairments and mobility-impairments, without giving much thought to deafness and speech pathologies. While I don't have a LOT of ideas about computer tools that would be useful, a few that come to mind are:
    • Text-to-Speech (a la Festival, etc, which I see mentioned just above this entry)
    • Speech-to-Text (a tougher problem)
    • ASCII-to-Baudot and vice versa (Really *-to-Baudot and Baudot-to-*)
    • Video-conferencing (mbone, openh323)
    • Accessible CMS system (Plone 2.1?) easy (This may be done by another group?)
  • Accessibility Center / Wizard (Jason Grieves) - to provide a central area for configuration and initial setup. This would entail bringing all of the "pieces" together under one roof. Never been done in Linux. (to my knowledge)
  • SpeechRecognition for Ubuntu would be nice.


Most accessibility features are only used by a relatively small part of the public, and therefore in may not be warranted to have them installed by default. Modularity is a widely recognised strength of Linux, which means you can install and activate just the features you want. Most people prefer a lean and uncluttered system that has just the components they need. Sticking to this principle leads to a less resource-hungry platform, which in turn extends the life of hardware and makes computing more affordable.

However, the task of installing components can be a major challenge for someone with a disability, because it may be precisely these features she needs to operate her computer normally. The optimal solution seems to be to leave these features un-installed by default, but to make it easy to install them. One solution is to make these features available during the install process (see: [Accessibility Aware Installer]), but there should also be simple options for installing these features on an existing setup. It would be helpful to have the most common packages stored on the users hard drive.

Desktop dialogues

Several existing desktop preference dialogues already deal with different aspects of assistive technology (see AccessibilityHowto), most notably the Assistive Technology Support dialogue. This would be greatly enhanced by adding an option to install these features directly from there. Specifically, it should be possible to install gok, gnopernicus and possibly dasher directly from the Assistive Technology Support dialogue.

The standard Gnome keyboard enhancements (such as Sticky-Keys, etc.) has an associated status notification utility in the form of a panel applet. It is often useful to be able to check visually whether one of the modifier keys is active, as the computer's behavior might otherwise seem rather unpredictable. Currently, this feature can only be activated by adding a panel applet in the normal way, requiring that you find it by chance. It would be useful to have a button somewhere on the keyboard enhancement dialogue, which activated this feature.

GNOME Display Manager (GDM)

The latest GDM does support accessibility features. This is useful because it allows the user to control of the system from the login on-ward. It seems from the Hoary wiki pages that a substantial reworking of GDM is planned for the next release, so it seems likely that the accessibility features will also be included.

AFAIK, GDM listens for certain keyboard input or mouse gestures to activate accessibility features once these features are installed and certain config changes are made to GDM. It might be preferable to have GDM listen for this input by default and then prompt the user if these features are not available: 'You have requested the screen magnifier. This feature is currently not installed on this system.' ('Click Install' now or 'Cancel'; installation requires password) This would work well on a private system, where accessibility features are already installed, but there may be issues on public terminals. (btw: the input signals are designed so that the average user is not likely to give them by accident; example: press Shift five times)

Command Line Utility

Many blind people mainly use the command line interface for their computing. It would therefore be useful to have a simple text-based script that allowed one to install and configure various usability enhancements.

Public terminals and privileges

On a private system the main user knows the primary password and so is able to install features system-wide. However, on a system installed at a library, school, university, etc. this will not be the case. This can be a limitation for someone who is traveling and needs to use publicly available systems. We should perhaps encourage sysadmins at public sites to install these features by default.


GNOME's interface has keyboard shortcuts to do just about every function one needs. However, some applications have the same keyboard shortcut for more than one function. The following is a list of applications that have been found to have such a problem, and what has been done to resolve the problem.

If you have found an application that has keyboard shortcut problems such as what has been outlined above, please list here. If you intend to get this problem resolved yourself, it is advisable that you contact the upstream author or authors first, so that changes will get filtered down to Ubuntu.

Applications with keyboard shortcut conflicts

  • Rhythmbox - The same keyboard shortcut for Search, Source, and Shuffle functions. A bug has been reported upstream not by me, but last comment was October 2004. CCd any more action to me, nothing has been done so far. (LukeYelavich)

  • Nautilus-cd-burner - The same keyboard shortcut for two options in the burn CD dialog box for Write disc to and the Write button. Reported bug upstream, has been resolved, and should see a change in Breezy some time soon. (LukeYelavich)

  • Gnome - Window switching shortcut is "@" in CF (french-Canadian) keyboard. Impossible to write any mail in Ubuntu 5.4 with "CF" keyboard

Accessibility Integration



Discusses how accessibility for blind and vision impaired people can be better integrated into Ubuntu.


The various accessibility tools for Linux do their job well for the environment they were written for. However, the tools do not always integrate with each other as well as they should. The authors of these tools often did so to scratch an itch to make Linux more accessible for themselves, not always worrying about whether the tool integrates well with other tools that perform a similar function. Overall accessibility could be improved if these tools could be integrated together to allow for a consistent and user-friendly environment in both GNOME and the console.

Scope and Use Cases

A blind/vision impaired person wishes to install Linux on their system. They want Linux to have a spoken installation procedure, and have speech output configured by the second stage of the install. Braille output for the install should also be available, with the Braille display automatically detected if possible.

A blind/vision impaired user wants the screen reader to function much the same in both the console and GNOME. Since GNOME's accessibility is not yet as good as what is available for the console, there is a chance the user will only use GNOME for some tasks. However, they would want to be able to set the various speech parameters in one environment, and have the same settings carry to the other.

The user may have also purchased a proprietary software synthesizer from the various companies that make such software available for Linux. They would want to install it, and use it in both environments.

The user may think there is a problem when Linux starts, due to the system taking a long time to boot, or for another reason. They should be able to get spoken output for as much or as little of the boot process as possible. They should always hear any boot errors that occur.

The user should be able to set which sound card they wish to hear speech from, if more than one sound card is present. This should not depend on the default sound card, but if the desired sound card is not present, the default sound card should be used.

The user should be able to use their Braille display in both environments with minimal configuration.

Implementation Plan

  • Write a userspace daemon that works with the Speakup screen reader, allowing user settings such as speech pitch and rate to be saved and loaded on-demand, as well as ensuring these settings are the same for gnopernicus in GNOME.
  • Create a package which is able to install the various Software speech synthesizers, asking the user for any input if necessary. This package will also pull in the various dependencies needed for the synth to work with GNOME and the console.
  • Modify the boot files to allow Speakup to be as verbose or quiet as the user wants. This means that the sound card modules and mixer settings will have to be loaded as early in the boot process as possible.
  • The speakup userspace daemon could perform the functions necessary to get Speakup heard out the specified sound card. It would also allow the user to select and configure how Speakup behaves during the boot process, including default sound card, and boot message verbocity.
  • BrlTTY is quite able to provide Braille display support for both GNOME and the console. Luckily, it is the most complete Braille display management package available, and integrates seamlessly.

Data Preservation and Migration

Packages Affected

  • Installer
  • lsb-base (Modify boot message functions to allow speech output.)
  • linux-source (Adding speakup to allow console screen reading.)
  • gnopernicus (Modify keystrokes to be much the same as speakup)
  • gdm
  • speech-dispatcher (The main package responsible for software speech with speakup.)
  • BrlTTY

User Interface Requirements

  • Ensure that the keyboard commands for speakup and gnopernicus are as similar as possible.
  • Develop a user-friendly way to modify the keyboard commands for speakup. This is currently possible, but not easy.

Outstanding Issues

We need to:

  • Work with the kernel team to get speakup into the kernel, with everything as modules.
  • Work with the audio guys to ensure that the userspace speakup daemon can use whatever sound card the user requests for speech output.
  • Work with the installer developers to get speech output for text and graphical installers as early as possible.
  • Write the speakup userspace daemon. A separate specification can be made for this daemon when necessary.
  • get gdm to work with gnopernicus for speech output.
  • Move a few packages from universe such as speech-dispatcher and BrlTTY into main.

Accessibility/OldContent (last edited 2008-08-06 16:19:11 by localhost)