Accessibility in Linux systems

And yet the issue of GNU/Linux accessibility, i.e. the usability of GNU/Linux by disabled people (e.g. blind people) is, of course, not new. Work in that area has been conducted for a long time: the speakup speech screen reader saw its 0.07 version against Linux 2.2.7 in 1999, and the brltty Braille screen reader started in 1995. The basic Braille screen reader that has just been added to the Linux kernel is just the emerging part of that work which has been around since then.

With the popularization of GNU/Linux among non-technical people, there has been renewed interest in mainline accessibility support: the GNOME desktop, OpenOffice.org and Firefox 3 can now be rendered via Braille and speech synthesis thanks to the AT-SPI framework and the Orca screen reader. KDE will soon follow when these technologies get rebased on D-BUS. In addition, accessibility menus have started appearing in the upstream distributions.

One of the main concerns for disabled people used to be the lack of support of Javascript in text-mode web browsers and office suite support. With more and more companies and governments migrating to Linux—particularly since some states require accessibility of tools used in government—renewed development effort was becoming more and more of a must. In Massachusetts, people had even signed a petition against the migration to libre software because it was not yet accessible at the time!

What is Accessibility?

Accessibility, sometimes abbreviated a11y, means making software usable by disabled people. That includes blind people of course, but also people who have low vision, are deaf, colorblind, have only one hand, can move only a few fingers, or even only the eyes. It also includes people with (even light) cognitive troubles or just not familiar with the language. Last but not least, it includes elderly people, who often have a bit of all these disabilities. Yes, that actually means everybody is concerned, eventually. That means support for special devices, but also general care during development, like not assuming that an audible alarm will be heard or a transient message will be read.

Maybe one of the most obvious accessibility techniques is speech synthesis, which turns text into audio that can be sent to speakers or headphones. There used to be hardware speech synthesis (supported by the speakup drivers), but these have often been replaced by software speech synthesis. While the quality of commercial software speech synthesis is very good these days, the quality of free software vary a lot. While there is very good libre English speech synthesis, the support of other languages is quite diverse. For instance, the Festival and eSpeak libre engines easily support a wide range of languages, but their sound is rather robotic. There are better phoneme libraries like mbrola, but they are often not completely libre. To better handle all these potential speech synthesis backends, the speech dispatcher daemon takes care of automatically choosing the appropriate synthesis according to the desired language and style.

Another very popular kind of device is Braille terminals. These "show" text by raising and lowering little pins which thus form Braille patterns. Because their cost is very high, a Braille terminal often has room for only 40 characters or even 20 or 12. They integrate keys to navigate around the screen, so the user ends up reading it piece by piece. Compared to speech synthesis, the reading accuracy is far better, but not everybody can read Braille, and the cost remains very high (on the order of $5,000). The support of the various existing devices is very good: both the brltty and suseblinux screen readers support a very wide range of devices.

Blind people will actually often use a combination of speech synthesis and Braille devices. As for other kinds of disabilities, the kind of devices varies a lot. It ranges from joysticks (natively supported by X.org) to eye-tracking systems (managed by dasher), via press button (supported by the GNOME Onscreen Keyboard) or mere screen magnification (implemented by gnome-mag).

Everyday Use

The eternal Command Line Interface vs Graphical User Interface flamewar actually also holds for people using a Braille terminal or speech synthesis. The contrast is perhaps even exacerbated by the inherent difficulties of performing anything with a computer when being disabled.

The old traditional way of using a GNU/Linux system, the text console, has been working well with Braille devices and speech synthesis for a long time. The principle is indeed quite simple: there are 25 lines of 80 characters and text appears sequentially. Screen readers for Braille terminals would thus just automatically display what was last written and permit the user to navigate among these 25 lines. Screen readers for speech synthesis (e.g. speakup or yasr) would speak text as it appears on the screen, and have some review facilities similar to what Braille screen readers have. This works quite well because applications are limited to the TTY interface, they cannot have non-accessible fancy features such as graphical buttons. Some applications may still not be so easy to read, e.g. if they draw ASCII art or use colors to show active buttons, but they often have options to get more accessible, a collection of tips can be found on this wiki.

Accessibility of graphical desktops is on the other hand a quite recent matter, in part because the issue is technically much less simple: while applications on the text console are limited to producing text, these days graphical applications usually render text as bitmaps themselves, so that the textual information is not available outside of the application for screen readers. There have been application adaptation attempts in the past (like ultrasonix), but they never really got popular. The GNOME project has been developing AT-SPI (Assistive Technology Service Provider Interface) for the past decade, and that has become really promising with the advent of the Orca screen reader. AT-SPI can be understood as a protocol between screen readers (e.g. Orca) and applications. To be "accessible", applications thus have to implement AT-SPI, or use a toolkit that implements it (like GTK and soon Qt), so that screen readers can get the logical and textual content of the application. Orca is not yet as good as what mature, proprietary Windows screen readers can achieve, but it is already usable for everyday work. It is progressing rapidly, notably thanks to the support of Sun and the involvement of the Accessibility Free Software Group. At the time of writing, only gtk+ 2 (and thus the GNOME desktop and gtk+ 2 applications), Java/Swing, the Mozilla suite, OpenOffice.org, and acrobat reader implement AT-SPI and thus are accessible. Qt (and thus the KDE desktop) is expected to support it once it gets rebased on D-BUS. To get the best results, the latest versions of applications should be used: for instance, Firefox is really usable only starting from version 3.

Another approach is the use of self-reading applications. For instance, Firevox is a version of Firefox that integrates a dedicated screen reader. That permits a tighter interaction between the reader and the application, but that is of course limited to that particular application. Another example is emacspeak, which is a vocalized version of emacs. Some people simply just use emacspeak and nothing else, as emacs already meets all their needs.

All in all, as usual the mileage varies. Some people will be very happy with the mature, efficient screen reading of the text console, while other people will consider that as a regression (like going back to DOS) and prefer using intuitive environments such as the GNOME desktop, even if the Orca screen reader is still quite young. It is actually quite common to use both: for instance the text console for the usual work, and the graphical environment for tasks that require it, like browsing Javascript-powered websites or manipulating OpenOffice documents.

Upstream Integration

Now, how can all of that be installed? Most distributions already provide most of the useful packages, but they often lack documentation on which tools are useful according to the various disabilities. The Linux Accessibility Resource Site is a quite complete source of information on the various tools that one could use. There is also a wiki page meant for administrators to get started with accessibility needs.

A point worth noting, however, is that some distributions have accessibility components built into their installation CDs. For instance, starting from Etch (aka Debian GNU/Linux 4.0), the Debian installer automatically detects Braille terminals and if found, switches to text mode, runs brltty, and makes sure that brltty gets installed and configured on the target system. Other distributions often have been non-officially adapted into so-called "Braillified" installation images. The very important point is that it permits disabled people to be completely independent from the help of sighted people, even when the (re)installation of a system has to be done! That is clearly one area in which Windows is far behind GNU/Linux achievements.

Future Challenges

To sum it up, "accessible" GNU/Linux is getting its democratization step as well, just a bit shifted in time compared to the average Linux democratization. There are, of course, things that could be improved. Even if distributions usually contain accessibility software, it is hard for accessibility-newcomers to know which software will be useful for the various kinds of disabilities users can have, so distributions will have to develop wizards to help them. In the meanwhile, websites such as the Linux Accessibility Resource Site can be used as sources of information. In any case, discussion with the disabled users is essential to establish a suitable solution (setting up Braille output would be useless if the user can not read Braille for instance).

Beyond the mere use of GNU/Linux or its installation, one area that still is not really accessible at all is the early stages of the boot process. With future development of the recently added basic Braille screen reader, the Linux kernel should eventually be able to provide basic feedback even before user space screen reader daemons can be started from the hard disk. Bootloaders like lilo and grub are able to emit basic beeps, but being able to accurately edit the kernel command line, for example, would require some support. Last but not least, tinkering with BIOS settings is currently possible for disabled people only on high-end machines that can drive a serial console. The democratization of the EFI platform could be an opportunity to embed basic screen reading functionalities.

[Samuel Thibault has been working on accessibility since 2002, when he and a blind colleague designed the BrlAPI client/server Braille output engine, now used by Orca for Braille support . Since then he has worked on various accessibility tasks, from the Debian installer support to Braille standardization. In his professional life, he conducted a PhD on thread scheduling on high-end machines, and is now a lecturer at the University of Bordeaux.]