OldContent

Revision 1 as of 2005-12-08 12:46:32

Clear message

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

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 [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.