This page is meant to gather information about accessible installers, originally targeted to developers. It originally documents how the Debian installer works (or at least plans to work for some parts), but ideas and improvements are welcome, our goal is to make all distributions as accessible as possible!

As usual, since there are a lot of kind of accessibility issues, there are a lot of possible solutions. Debian has a few basic ones, which for now only covers blindness, low vision and color blindness, so this is a very small part of all kinds of disabilities that users can have. This is a wiki, please contribute!

Documentation worth reading is [http://www.tldp.org/HOWTO/Accessibility-Dev-HOWTO/ the accessibility developper howto], [http://www.tldp.org/HOWTO/Accessibility-HOWTO/ the accessibility howto] and the [http://larswiki.atrc.utoronto.ca/wiki LarsWiki].

Braille support

The very neat thing with braille devices is that most USB ones can be automatically detected thanks to USB IDs. The brltty package's Hotplug/udev.rules is a script that can be added to the installer to automatically trigger starting brltty when a braille device is detected. Note however that it is a bit generic, and include rules which would trigger with a mere usb to serial converter! As of brltty 4.3, 0403:6001 and 10c4:ea60 are actually mere serial to usb IDs. In the case of serial port devices, autodetection can not be done (it is even dangerous for some devices). To still permit using serial braille devices, when the kernel command line contains "brltty=" brltty should be started with the -E option, to make it read /proc/cmdline itself and find its parameters. Some documentation for the parameters is available on http://brl.thefreecat.org/wiki/moin.cgi/brltty but brltty will handle all the details anyway.

Starting brltty is already a very good thing, as it supports a very large range of braille devices. But now it needs to access the content of the installer. The Orca screen reader can usually read GTK applications, but it may not be very convenient, see more about it below. The usual way is rather to automatically switch to a textual version of the installer, which brltty will be able to read. Really textual, not an fbterm (fbcon is fine however). Also, if a special flavor of the Linux kernel is used, it must be ensured that /dev/vcsa and /dev/tty0 are available, the keyboard of some devices will also need uinput for proper layout support, and USB-to-serial device drivers should be included.

For instance, Debian has a /lib/brltty/brltty.sh script as follows:

pid=/var/run/brltty
[ -r $pid ] && kill -0 `cat $pid` && exit 0
exec /sbin/brltty -P $pid "$@"

which is invoked by the udev rules mentioned above, but also by the following script, always run at boot:

grep -q brltty /proc/cmdline && /lib/brltty/brltty.sh -E
pid=/var/run/brltty
[ -r $pid ] && kill -0 `cat $pid` && debconf-set debian-installer/framebuffer false

which does call brltty.sh by hand if brltty is on the kernel command line, and then if the pid file exists (either because brltty.sh was called from udev or by hand just above) and the daemon is still running (i.e. no error), then the framebuffer version of the debian installer is disabled, thus disabling the graphical installer or the use of bterm.

Now, the problem could be that you don't have a braille device to test with. Well, qemu has one for you! http://wiki.debian.org/DebianInstaller/Accessibility explains how to test the braille support of the debian installer, but this is applicable to any distribution.

If you want to reduce the amount of space used by the brltty daemon, you need to be aware that the .ttb and .tti files are of utmost importance: they are a bit like the "fonts" that e.g. asian people need to be able to read their language, each language has its own flavor of braille, and reading one with the other is from tedious to impossible.

Speaking about tables, it is worth knowing that it is next to impossible to properly know which table the user will want, so it is preferrable to just point her/him at http://www.mielke.cc/brltty/doc/drivers/ so he/she knows how to enter the braille preference menu and chose her/his table.

Note: there are already "braillified" versions of some distribution installation CDs, http://mielke.cc/brltty/download.html has for Fedora and RedHat.

Speech support

There are two main kinds of speech support: hardware and software.

Hardware speech support

They can be internal boards or external serial devices, some are USB. To my knowledge, only speakup supports them. Speakup is a collection of kernel modules that can be loaded to both drive the device and read the screen. Unfortunately, it doesn't support USB (yet) and has thus no autodetection. To enable speakup, the convention is to pass on the kernel command line speakup.synth=somedriver . The installer should notice that and modprobe speakup_somedriver to get speakup started.

Like brltty, speakup can only read textmode content, and thus the installer needs to avoid using a graphical installer or an fbterm (fbcon is fine however). One additional recommandation is however to use linear text: while braille devices permit to easily review the whole screen, doing the same with speech synthesis is very tedious. It is thus much better if the installer just emits its question as mere text on stdout (i.e. nothing like curses, dialog, etc) and requests textual answers ('1-9'-like answers for choices for instance). Ideally, the user should just need to listen carefully, type the answer, etc.

For instance, Debian does the following at boot:

SYNTH=$(sed < /proc/cmdline -n -e 's/.*speakup\.synth=\([^ ]*\).*/\1/p')
if [ -n "$SYNTH" ]; then
        modprobe speakup_$SYNTH
        debconf-set debian-installer/framebuffer false
        DEBIAN_FRONTEND=text
        export DEBIAN_FRONTEND
fi

to modprobe speakup, and disable the graphical installer or bterm use, and enable the textual interface instead of the newt interface.

Testing the support is very simple, as described on http://wiki.debian.org/DebianInstaller/Accessibility : just use speakup.synth=dummy , and monitor on the serial port what would have been spoken by a hardware synth.

There are already some "speakupmodified" versions of some distribution installation CDs, on http://speakupmodified.org/

Software speech support

Unfortunately, there is no very good completely free (as in freedom) speech synthesis. Espeak is quite good in that it supports a large variety of languages and is not so hard to extend. The quality is not so great, but it can do its job. If the distribution doesn't mind shipping free but non-free software, the mbrola speech synthesis is very good (but not really free). Of course, the usual kernel sound drivers are needed for the actual sound emission.

Now a screen reader is needed. It can actually also be speakup: modprobe speakup_soft, and use espeakup, which is a daemon that connects with speakup, to speak what the latter wants through espeak. Some other screen readers exist with other principles, like yasr, brltty itself too.

In Debian, it can be activated at the boot menu by pressing s and enter, or the end key and enter (since it's the last menu choice).

Low vision and color blindness

A lot of people are not completely blind, but have low vision, (e.g. for instance probably your parents or grand-parents). In such case, a simple theme helps a lot the accessibility of the installer. Use high constrast, e.g. white on black. Do not use decorations, or the bare minimum. Do not use colors to convey information, use caracters or simple drawings. Increase the font and cursor sizes. To enable this mode in the Debian installer to get an idea, pass theme=dark on the kernel command line. Ideally, various themes should be proposed, developped by testers themselves, since the kind of disability varies extremely!

Graphical installer and non-blind disabilities

As mentioned above, a graphical installer may not be the most convient interface for blind people. Indeed, a text console, i.e. 25 lines of 80 characters, is at least exactly what is shown on the screen, no more, no less, and the blind user is on par with sighted users. Still, some blind users will prefer a graphical interface and use Orca due to better intuitiveness.

For braille support, Orca relies on the brltty support, through the BrlAPI interface, which uses a local socket in /var/lib/BrlAPI and an authentication key /etc/brlapi.key. In the installer case, the authentication phase can probably be dropped, to do so pass -A auth=none to brltty.

For non-blind disabilities, a graphical installer seems to be usually fine, provided that some helpers are started. These can probably be the same as those that are usually started for e.g. a usual gnome desktop. The following is a non-exhaustive list:

Of course, making the installer questions simple and understandable by people who are not computer specialists is one of the first accessibility features to implement :)

Reboot

One thing that mustn't be overlooked is the reboot. Enabling accessibility facilities at installation time is good, but e.g. starting Xorg systematically is not necessarily a good thing! Installing Xorg like regular installs is a good idea, at least so that the same set of packages is installed, to avoid differences with mainline when it comes to bug reports. However, when the installation has been done through some accessibility way, at first reboot the system should again enable exactly the same accessibility ways. Then the user can enable Xorg & such if he wants to.

In the brltty case, if the user passed a brltty=aa[,bb[,cc]] kernel parameter, the following /etc/brltty.conf should be created (yes, bb and cc are optional):

braille-driver aa
braille-device bb
text-table cc

About kernel parameters

It is of course out of question to systematically enable e.g. speech synthesis on regular installer images, so at least *some* activation has to be done manually. In the case of braille devices, the USB autodetection is great, but far from everybody can afford braille devices or even be able to use it.

Traditionnally "cheatcodes" are passed on the kernel command line. This is very powerful and permits to configure devices, choose the language etc. The problem is that bootloaders are not themselves accessible, and so the cheatcodes have to be typed blindly, with a qwerty keyboard layout. This isn't very convenient, to say the least. It is better to have predefined boot entries. The problem is: how to select them? As mentioned above, the last entry could be a very well-known one. Another approach would be to use standardized shortcuts, something like "control-F8 shall start software speech synthesis". There is no such standard yet, but it could be a good approach.

Also, it is hard to know when exactly the cheatcode can be typed. Trying to listening to the CD spin up and down doesn't really work reliably :) It was a long discussion, but the Debian-boot team agreed to add emiting a beep when the boot menu is ready. This has been enabled in Lenny and I am not aware of complaints from administrators, so it seems that this is "OK" and could be generalized. Yes, just a mere beep can mean a lot when dealing with accessibility.

Another way to go can be what Debian calls preseeding: even when using a standard installation CD, parameters can be kept in a small file on a USB key, containing all the parameters for the various accessibility features to be enabled. Such a file could be automatically generated for the user by a website after filling some form.

Last remark

Don't hesitate to ask me (samuel.thibault@ens-lyon.org) more, or discussion with the debian-accessibility@lists.debian.org mailing list.


CategoryDistributions

None: Installer (last edited 2011-12-30 00:44:39 by SamuelThibault)