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.

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 [http://shots.osdir.com/slideshows/slideshow.php?release=305&slide=2 this] page or [http://shots.osdir.com/slideshows/slideshow.php?release=305&slide=4 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 [http://www.ubuntulinux.org/wiki/AccessibleHoaryLiveCDDerivative 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

• Installer

• The [http://www.ubuntulinux.org/wiki/AccessibleHoaryLiveCDDerivative Accessible Hoary LiveCD] page mentions a number of other packages which have already been modified.

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 [http://shots.osdir.com/slideshows/slideshow.php?release=305&slide=2 this] page or [http://shots.osdir.com/slideshows/slideshow.php?release=305&slide=4 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.

Ideas

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

Development Goals

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.

SingleClickInstall

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)

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