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].
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 5.2, 0403:6001, 10c4:ea60 and 10c4:ea80 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/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 by default. Really textual, not an fbterm, whose content will be completely inaccessible (the fbcon kernel module 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.
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 as in free beer but non-free as in free speech" software, the mbrola speech synthesis is very good (but not free as in free speech). Of course, the usual kernel sound drivers are needed for the actual sound emission. The pico (or svox) speech synthesis from Android is also good but only almost free.
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-ng and portaudio (pulseaudio is not strictly necessary). 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).
It's preferrable to switch the language when the user has chosen it espeakup can simply be restarted with a -V option. Typically, espeakup would be started first in english for presenting the language choice selection, and once the language is selected, espeakup is restarted in the chosen language. The list of supported languages can be read from the "language" lines of /usr/lib/*/espeak-ng-data/voices
In case the system has several audio cards, one has to chose the proper one through the ALSA_CARD environment variable. A simple way is to start espeakup with a given card, echo "Please type enter to use this sound board", wait for enter for a few seconds, then retry with the next card, etc. in a loop, and record the 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:
- Orca provides speech support (which can be useful for people with reading disabilities), magnification support (for low vision) and a few color filters (for colorblindness).
- AccessX can be used by people with typing disabilities.
- gok can be used by people who have very limited typing capabilities, which can be as severe as just being able to click one button.
- Some people need to have the whole screen inverted left-right. A mere xrandr -x call should be enough.
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
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.