Non-Visual Access to Linux from Bootup to Shutdown

Table of Contents

1 Abstract

As Janina Sajka has stated, "equal access to all system functions is a blind computer user's right, from bootup to shutdown". This presentation examines the extent to which such equality has been achieved, focusing on the characteristics which enhance, and hinder, non-visual access to the Linux environment. Where limitations are identified, opportunities for further improvement are noted, and strategies that blind Linux users can employ to circumvent these obstacles are described.

More broadly, this talk is intended to answer a question of interest to the free and open-source development community, namely, how to build software, be it a component of the operating system or an application, which is amenable to non-visual access. The expository strategy is to consider the activities of a competent Linux user or administrator - all the way from bootup to shutdown - and to analyze the accessibility-related aspects of the different types of user interface encountered along the way. Examples are drawn from command line tools, ncurses applications, X11 desktops and the Emacs environment. Although the speech and braille access software employed by users who are blind will be briefly introduced, as needed, the focus of the talk is firmly directed to the accessibility of the operating system as well as that of free and open-source applications.

2 Braille and Speech Access Tools Summarized

An overview of significant braille and speech-based access software available in the Linux environment is presented in the following table, as conceptual background to the subsequent discussion. Only the most important and active projects are included. For a more thorough introduction to braille and speech-based interfaces in a Linux environment, including an overview of refreshable braille and speech synthesis, see my LCA 2008 talk (audio and video are available, linked to the LCA 2008 programme).

NameOutput ModalitiesDescription
BRLTTYbraille, speech (used in conjunction with a braille device)A braille interface to the Linux console, and via BrlAPI, to other tools that control refreshable braille devices.
SpeakupspeechA screen reader for the console, included in the Linux kernel (in staging as of 2.6.37).
EmacspeakspeechA speech interface to Emacs, including many extensions
Orcabraille, speech, screen magnificationOrca is a screen reader for the GNOME desktop. Braille support is provided via BrlAPI/BRLTTY

3 Notes on the Boot Process

3.1 Firmware

Depending on the machine, any of the following access methods may be available.

  • Serial console (typically non-x86 systems and servers)
  • Serial-over-LAN (IPMI 2.0)
  • None whatsoever (the typical x86 case)

3.2 Boot Loader

  • Using GRUB via a Serial Line
  • GRUB 2 supports the GRUB_INIT_TUNE option, which plays a tune on the speaker when the GRUB menu appears
  • Without serial access, no braille or speech output is possible, but when the tune is played, at least the user knows that it's time to type (e.g., to press down-arrow to move to the single user mode boot item).
  • To access a KVM guest on a virtual terminal of the host, including the boot loader
    1. Ensure that the boot loader uses a textual display (i.e., no graphics mode), for example, GRUB_TERMINAL=console in GRUB 2
    2. Specify the -curses option to qemu-kvm. The -show-cursor option is also useful.

3.3 The Rest of the Boot Process

  • Serial console
  • netconsole transfers kernel log messages to another host via UDP
  • BRLTTY can be included in the initrd image
  • Speakup can start early in the boot process
  • login: prompts can be read with BRLTTY or Speakup
  • Orca: accessible login with GDM

4 The Console

In general, braille and speech-based access to the console is excellent. This user interface, inherited from the UNIX tradition, is a fundamental advantage that helps to make Linux preferable to certain other proprietary operating systems. Almost all tools and applications are completely accessible without modification.

4.1 Enhancing Access to Terminal (ncurses) Applications

  • Cursor handling can be problematic
  • Regularly updated status lines can annoy speech users
  • Enhancements to overcome these difficulties are easily made to applications

Examples of configuration options which facilitate non-visual access to popular terminal applications are presented in the following table.

ApplicationOptionEffect
Muttset braille_friendly=yesWhen the body of a message is displayed, places the cursor on its first line
Alpineshow-cursor, in feature-list parameterUse the terminal cursor instead of a highlight bar
Alpinesingle-column-folder-list, in feature-list parameterPresents the folder list in a second column
LynxSHOW_CURSOR:TRUEUses the terminal cursor instead of a highlight bar
LynxDEFAULT_KEYPAD_MODE:LINKS_AND_FIELDS_ARE_NUMBEREDLabels links and fields numerically, enabling them to be selected directly by typing the associated numbers
Vimset norulerTurns off the status display of the cursor position, which tends to annoy speech users

5 Emacs

GNU Emacs is highly accessible via speech output, when used with Emacspeak. For braille access, it must be run from a terminal rather than as a GTK+ application.

To enhance Emacspeak to provide a quality speech interface to an Emacs extension, the Emacs advice facility is used.

  • Speech actions can be performed whenever a function is executed
  • Voice parameters can be changed to convey syntax highlighting and other desired meaning
  • Auditory icons (brief sounds) can be used to enhance the user interface by conveying information quickly and efficiently

6 Graphical Desktop Environments

To be accessible with Orca, applications and GUI libraries must support the GNOME Accessibility API. applications must also be usable with keyboard input alone. The extent to which graphical applications are accessible depends on the correctness and completeness of their support for the accessibility API.

Better documentation of the accessibility interfaces (ATK and AT-SPI) is presently under development.

6.1 Examples of Projects that Support the Accessibility API

In addition to the core GNOME desktop itself, various applications support the accessibility API. Bugs, including regressions, can render part or all of an application inaccessible to Orca users.

Projects which use the GNOME Accessibility API, and which are therefore intended to be accessible with Orca, include the following.

Source: Orca scripts directory.

6.2 Limitations and Challenges

  • Transition to AT-SPI 2, a re-implementation that uses DBus as its inter-process communication mechanism
  • See the Gnome 3 site for details of required development work
  • The need for more development
  • Need for better testing and integration by distributors; distributing packages that compile and minimally execute is not sufficient for accessibility
  • QT applications and KDE are presently not supported at all; this needs to be revisited in view of AT-SPI 2

7 Web Applications

ARIA (Accessible Rich Internet Applications) extends the concept of an accessibility API to the Web. User interface controls implemented in Javascript can be made accessible by including support for ARIA attributes.

Free and open-source Javascript user interface libraries and generators that support ARIA include:

8 Shutdown

In the event of an abnormal shutdown, a kernel panic, the following tools may be useful.

  • Serial console
  • Network console (netconsole)
  • Speakup
  • kexec

Author: Jason White

Date: 2011-01-22 13:43:38 EST

HTML generated by org-mode 7.4 in emacs 23