The Linux kernel recently saw the addition of a "basic Braille screen reader",
and thus, the addition of a
subdirectory and its
corresponding CONFIG_ACCESSIBILITY option. It is worth noting that one of the
first reactions was "what the heck is accessibility?" This shows how the idea
is still quite unknown to developers.
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
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
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
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,
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
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.
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
good: both the brltty and suseblinux screen readers support a very wide range of
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).
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
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
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
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
(re)installation of a system has to be done! That is clearly one area in which
Windows is far behind GNU/Linux achievements.
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.
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
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
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
colleague designed the BrlAPI client/server Braille output engine, now
used by Orca for Braille support . Since then he has worked on various
tasks, from the Debian installer support to Braille standardization. In his
professional life, he conducted a PhD on thread scheduling on high-end
and is now a lecturer at the University of Bordeaux.]
to post comments)