Creating accessible applications with Eclipse: An introduction

Hand on Computer Screen illustrationLevel: Introductory Mark Pilgrim, Accessibility Architect, IBM
Barry Feigenbaum, Worldwide Accessibility Center, IBM
Richard Schwerdtfeger, Distinguished Engineer, IBM
Kip Harris, Worldwide Accessibility Center, IBM
15 Dec 2005

from The Rational Edge: This first article in a new series on building accessible applications with Eclipse begins by looking at assistive technologies and disabilities. It then discusses the functions and features that make Eclipse well suited for creating accessible applications on Windows or UNIX.  

Accessibility is an umbrella term that covers everything and everyone involved in making a product usable by people with different abilities. Software accessibility has become a rapidly expanding field that encompasses all of the following:

  • Creation of application programming interfaces (APIs) for application developers that expose a program’s user interface to other programs.
  • Creation and incorporation of assistive technologies (ATs) — third-party software and hardware that hooks into an application’s accessibility APIs.
  • Compliance with the legal accessibility requirements mandated by several countries, including the US.
  • Accommodating end users with a variety of abilities and disabilities.
  • Ensuring interoperability for system accessibility features.

In the US, the primary commercial (versus humanitarian) driver for making applications accessible is a 1998 amendment to the Rehabilitation Act, known as Section 508. Requiring federal agencies to make their information technology accessible to people with disabilities, Section 508 applies to all information technology procurements within these agencies, with certain exceptions (see Appendix).  

State and local governments are instituting similar regulatory requirements, as is the public sector worldwide. These requirements have already started to cascade into private industry, with large companies leading the way. Many of them now include accessibility requirements in their purchasing specifications. This is the first in a series of articles that will offer guidelines for creating accessible open-source applications with Eclipse, a technology that makes it easy to achieve the interoperability and ease of use required for people with many different kinds of disabilities.

We begin this first article with a brief look at assistive technologies and requirements for software development. Then, we discuss why the Eclipse technology is a good choice for developers attempting to fulfill these requirements.

Assistive technologies (ATs)

An accessible solution combines an enabled product and one or more ATs targeted for a user with an impairment. You create an accessible solution by enabling your product for accessibility during product design and development. This is analogous to enabling software for internationalization; that is, you build the infrastructure to facilitate the addition of functions later on. Then, when you deploy an accessible product in a work setting for people with disabilities, you can readily pair it with a complementary AT to create a complete solution. The AT interprets the enabled software and allows users to interface with hardware via a variety of alternative access methods.

Common types of ATs include:

  • Screen readers that translate text to speech and “read” the software to people who are blind.
  • Screen magnifiers that enlarge information on the screen for people with low vision.
  • Closed captioning displays for people who are deaf or hard of hearing.
  • Special keyboards and input devices for people with limited hand use or mobility impairments.
  • Operating system features, such as keyboard response, high contrast, mouse keys, SoundSentry, and ShowSounds.

An AT can be effective only when the software and hardware with which it interfaces has all of the components necessary to make it accessible. For example, a screen reader cannot help a blind person read informational graphic images on a Web page unless the developer has provided alternative text for those images. To help developers create accessible applications, software programming platforms must provide a means for applications to export information about their visual user interface to AT products and for ATs to control user interface (UI) components. In other words, these platforms should have a standard accessibility architecture.

Screen readers

To understand what this implies, we must think about how an AT functions. As an example, let’s look at screen readers, which provide an alternative user interface for applications and the desktop on which they run in the form of Braille or speech, to assist users who are blind.

When all information drawn on a computer screen consisted simply of lines of ASCII text, it was not difficult for a screen reader to read a screen image and then present the text out loud to a blind user. However, with the advent of graphical user interfaces (GUIs), screen readers needed additional semantics to understand graphical screen objects. For example, what a sighted user sees and understands as a button, a screen reader perceives as a rectangle with rasterized text inside; there is no implied function associated with this rectangle (the same is true for many icons and other GUI components). Therefore, the screen reader needs a standard way — such as that provided by standard controls under the Microsoft® Active Accessibility (MSAA) for native GUIs or the Java™ Accessibility API (JAA) for Swing™ GUIs — to understand and communicate to the blind user that there is a selectable button on the screen. These APIs are based on object technology that enables application GUI objects (i.e., components, widgets, or controls) to export information about themselves.

Screen readers and other ATs use operating systems, programming platforms, and application resources to provide a specialized input or output method for the user. On some platforms, screen readers can extract text information directly from GUI applications that have implemented the standard accessibility architecture. The screen reader then renders that information using specialized text-to-speech hardware, software speech synthesizers, Braille displays, or some combination thereof. Readers on other platforms use a combination of off-screen modeling and heuristics to extract text from GUI applications. As this method is often unreliable, it is best if applications also fully support textual accessibility APIs if they are available for the platform.

Screen magnifiers

Screen magnifiers provide an alternative UI for an application and the desktop on which it runs in the form of a magnified desktop with optional font smoothing and specialized color themes. Typically, screen magnifiers are designed to follow either keyboard focus or the mouse. The magnifier picks a rectangular area around the “point of regard” and stretches it to fill the screen (see Figure 1). Some screen magnifiers also include a text-to-speech interface (like that of a screen reader) for those with severely low vision. For all the functions these ATs perform, access to an engineered accessibility API is essential.

GNOME screen magnifierFigure 1: GNOME™ screen magnifier

As Figure 1 shows, the screen magnifier in the GNU Object Model Environment (GNOME) desktop leaves half the screen functioning normally; in the other half, it displays a magnified view, with crosshairs showing the cursor position.

High-contrast theme

Operating systems provide theming mechanisms designed to support accessibility. Users who are either color-blind or have low vision benefit from the high-contrast color schemes these mechanisms can supply. The screen in Figure 2 shows this accessibility option, along with others provided in the Microsoft Windows XP® operating system. The GNOME desktop also provides multiple themes, including the high-contrast theme shown in Figure 3.

Accessibility options in Windows XPFigure 2: Accessibility options in Windows XP

Ideally, application components should be architected to enable the same changes in system font and color that the user specifies.

High-contrast theme on GNOME desktopFigure 3: High-contrast theme on GNOME desktop

Eclipse makes use of standard desktop widgets in the Standard Widget Toolkit (SWT) that enable responses to these changes. For other graphic elements, you can use pseudo-colors that automatically respond to color changes in the underlying operating system. If this is not possible, you must provide an alternate way to change colors.

On-screen keyboard

Both GNOME and Windows desktops provide on-screen keyboards (see Figures 4 and 5) designed to respond to input from alternate input devices, such as single switch devices. The on-screen keyboard automatically cycles through additional keys that may be entered into an application and activated via an alternate input device.

GNOME also includes a word prediction capability. When a user begins entering a common word, the system will offer to complete it, so that the user need not enter every letter.

GNOME on-screen keyboard (GOK)Figure 4: GNOME on-screen keyboard (GOK)

On-screen keyboard for Windows XPFigure 5: On-screen keyboard for Windows XP

It is important that applications are architected to work properly with specialized input devices such as on-screen keyboards.

Other alternative input devices include single switch devices, devices that track head movements, and alternative keyboards for persons with mobility impairments. Typically, these can masquerade as a conventional mouse or keyboard. Because operating systems manage interaction with conventional mice, keyboards, and other input devices, applications that use a standard accessibility API correctly can also operate with these specialized input devices.

Sticky keys

Accessible desktops also provide keyboard filtering mechanisms such as sticky keys, bounce keys, and repeat keys to adapt keyboard response for persons with mobility impairements.

Sticky keys allow regular keystrokes to “stick” for a designated period of time, allowing the user to complete a “chord” — a collection of keys that must be activated at the same time. The common command Ctrl-Alt-Del is an example of such a chord.

Visual cues for audio signals

Operating systems also supply ATs for assisting users with hearing impairments. For example, SoundSentry displays icons and other visual cues to indicate that the system has sounded an alarm or other warning.

Targeting disabilities

Our discussion so far has mentioned a number of disabilities. Let’s look more closely at these and other conditions that software platforms and applications may need to accommodate.

Blindness, low vision, and color blindness

People who are blind cannot see the screen at all. For them, using a mouse is almost impossible, even with the aid of an AT designed for people with limited mobility. Instead, they must use ATs such as screen readers to interpret information on the screen in a meaningful way. A screen reader provides a continuous auditory representation of what’s on the screen, what options are available, what user interface control has focus, and what changes are taking place. Another option is a Braille rendering device. However, only about 10 percent of vision-impaired people can read Braille, and even those who do, typically use a combination of Braille and text-to-speech devices for the computer.

People with low vision have difficulty seeing the screen and typically use a screen magnifier to select and enlarge portions of it. All modern operating systems provide a basic screen magnifier. Third-party products can provide additional functionality, such as a “theme” that enlarges fonts system-wide or one that provides high contrast between background and foreground.

People who are color-blind generally use computers without assistive technology, but they cannot distinguish certain colors. There are several types of color blindness, but the most common — an inability to distinguish red from green — affects 6 to 10 percent of men.

Suppliers should provide accessible versions of printed product documentation for people with any level of visual impairment.

Technical requirements

These people may require the following:

  • Text descriptions for images
  • Keyboard capabilities that provide alternate access for all functions normally accessible via a mouse
  • Screen or Web readers
  • Text and semantics transformation to speech or Braille
  • Large fonts, high contrast, and screen magnification

Deaf, hearing-impaired, and hard-of-hearing users

Deaf and hearing-impaired customers either cannot hear, or have difficulty hearing, auditory alerts and multimedia presentations.

For deaf users, audio information must be converted to text that can be displayed or printed. Some modern operating systems provide system-wide settings that automatically either generate a visual warning whenever there is an auditory alert or provide specific text captions for auditory alerts. All multimedia formats provide their own closed captioning APIs.

Technical requirements

These people may require the following:

  • Visual indication of sound
  • Captioning
  • Adjustable volume
  • Teletype (TTY®) or telephone device for the deaf (TDD) interface
  • High signal-to-noise ratio

Mobility impaired users

This category encompasses a wide range of disabilities, ranging from people with Parkinson’s disease who have difficulty controlling their hand movements, to people who have lost the use of an arm after suffering a stroke, to amputees who have no arms at all.

People who are mobility impaired may have difficulty using a mouse. Parapalegics generally use a cursor-pointing device that attaches to the head; they move their head to move the cursor on screen and blow through a tube in their mouth to click the mouse. Those with some use of their hands can use the on-screen keyboard we described above. In addition, stroke victims and other mobility-impaired people who can use the standard keyboard but have difficulty typing combinations that require holding down multiple keys at once can use operating system settings that allow them to type these keys one at a time, in sequence.

Technical requirements

These people may require the following:

  • Accommodation for limited or no use of hands or fingers
  • Accommodation for limited range, speed, and strength
  • Accessible switch and latch placement
  • Multiple key input
  • Capability to set key response times

Cognitively impaired users

This category also encompasses a wide range of disabilities, but generally refers to people who have difficulty understanding what they read.

A user with reading disabilities may need the ability to adjust text foreground and background colors and/or adjust spacing between letters and words.

Technical requirements

These people may require the following:

  • Adjustable white space between words and lines
  • Foreground and background color selection, to improve readability
  • De-emphasis of “connecting” words (conjunctions, articles)
  • Capability to set timing
  • Bi-modal (print and audio) information delivery
  • Spotlighting to guide eyes from word to word
  • Use of images to replace text

Now that we have a basic understanding of existing ATs and the various disabilities developers need to address, let’s turn to the role that Eclipse can play in developing accessible software.

What is Eclipse?

The Eclipse environment provides a set of components for building new applications. Within IBM, we have used Eclipse technology to build applications ranging from the IBM WebSphere Studio family of products to IBM Tivoli configuration utilities and the next generation of the IBM Lotus Rich Client. A key Eclipse feature is that it runs across a broad range of operating environments, including all of the strategic IBM platforms in client environments.

An Eclipse operating environment comprises processor architecture, an operating system, a windowing system, and a Java runtime environment. Within the context of an accessibility discussion, the operating system and windowing system are the key variables.

For performance and other reasons, the Eclipse GUI library directly uses the operating system that widgets provide by wrapping them in a thin Java layer. These components are also used by native client applications and need to interface to native platform accessibility features. Therefore, platform accessibility support is a prerequisite to delivering accessibility features in Eclipse. Eclipse contains a platform GUI abstraction layer and an accessibility API that is typically mapped to native operating system platform frameworks. Currently, the Eclipse accessibility implementation supports the Windows operating system and is being extended to support any UNIX platform with the GNOME Toolkit (GTK) widget set (such as the GNOME desktop). Considerations required for other desktops and other operating systems, such as Mac OS X, are beyond the scope of this article.

How Eclipse enables accessibility

Accessibility features for the Windows platform were implemented in Eclipse 2.0 and further refined and stabilized in Eclipse 2.1. Basic support for the GNOME platform was added in Eclipse 3.0. Major AT vendors participate in ongoing efforts to test their products for interoperability on Eclipse, to ensure that the technology will remain completely accessible across all supported platforms.

In addition, Eclipse has an accessibility package that includes an API: org.eclipse.swt.accessibility. Although they are written in Java, Eclipse applications follow the accessibility API of the target desktop operating system. Eclipse provides a rich plug-in environment, in which the norm is to create plug-ins for native widgets. Most of the SWT widgets that come with Eclipse are actually Java wrappers for native GUI widgets (as opposed to a pure Java GUI like Swing, whose higher-level components do not translate to native operating system widgets).

Eclipse 3.0 accessibility features are based on the capabilities provided by the MSAA 1.3 programming model. You can associate an Accessible object in Eclipse with each control, and the set of methods in the org.eclipse.swt.accessibility interfaces corresponds to the set of messages in the MSAA 1.3 IAccessible interface.

The SWT Accessible object provides a bridge that routes accessibility related messages from the underlying platform framework to the SWT widgets used by an application — so that application components can provide accessibility information back to the platform. The platform accessibility architecture defines the interface between the platform accessibility framework and the AT user agents. Figure 6 illustrates this arrangement.

Components of an accessible Eclipse-based solutionFigure 6: Components of an accessible Eclipse-based solution

The three components in Figure 6 are:

  1. The application (or plug-in), which is built using SWT. This component is platform independent, since SWT isolates the application from the platform. The org.eclipse.swt.accessibility package runtime provides the bridge from the application to the platform.
  2. The platform accessibility framework, such as Windows MSAA or GNOME Accessibilty Project (GAP).
  3. The AT, such as the JAWS screen reader. At runtime, the AT obtains information about the user interface elements by calling the platform accessibility framework, which in turn calls into the .swt.accessibility package.

org.eclipse.swt.accessibility design goals

The org.eclipse.swt.accessibility package is designed to provide Eclipse developers with the set of facilities they need to enable an application for interoperability with ATs on any platform that supports these technologies. Currently, Eclipse integrates with the accessibility platforms on Windows and Linux GTK.

From an IBM perspective, this work entails several requirements for application developers:

  • Providing visual and programmatic focus.
  • Respecting system settings for high contrast, colors, and large fonts, or providing application-specific alternatives.
  • Providing textual names and descriptions for interface elements.
  • Providing semantic information, such as roles of objects and relationships between them.
  • Providing the ability to navigate and access all functions using the keyboard.

The facilities of the underlying platform accessibility frameworks will accommodate these requirements to varying degrees. On Windows, for example, MSAA generally provides facilities for obtaining names and descriptions of UI elements, but only limited ability to define relationships between the elements.

The cross-platform Eclipse org.eclipse.swt.accessibility package actually provides one or more improvements in accessibility support for developers over what is available in the underlying Windows platform. The Windows MSAA design does not generally give developers control over the accessibility attributes on UI elements. The names and descriptions are automatically decided by MSAA, based on internal algorithms specific to each control. For example, MSAA automatically uses the text on a button as the MSAA name property. If a developer wants to provide a different name or description, then he must undertake the expensive task of creating an MSAA proxy. However, Eclipse org.eclipse.swt.accessibility performs the proxy work automatically. So developers can easily define appropriate attribute values for the various UI elements (such as accessible name and description), all within the SWT environment.

Changes in Eclipse 3.0

Several key accessibility features were added in the Eclipse 3.0 release.

First, the existing org.eclipse.swt.accessibility API, as defined in release 2.1, is now supported on the Linux®/GNOME platform. Furthermore, GNOME has a new set of features for text controls.

New facilities for developing accessible text widgets are provided through the AccessibleTextListener interface (and corresponding AccessibleTextAdapter and AccessibleTextEvent classes), and the three new text{*} methods on org.eclipse.swt.accessibility.Accessible. These new facilities are based on a small subset of those from AtkText interface from the GNOME Accessibility Project. A richer text API might include functions for retrieving location information for text sub-ranges and style attributes; these functions are not currently available in Eclipse.

Cross-platform API compatibility

The Eclipse accessibility API works on multiple platforms, despite wide differences in the underlying accessibility APIs for each operating system.

On the Windows platform, most of the available functionality for operating accessibility features is provided through a single MSAA interface: the IAccessible interface. This interface defines MSAA 1.3 properties and methods for the most common attributes and behaviors, and provides access to all UI controls.

When a particular property or method is not applicable to a particular type of UI element, the property becomes a “don’t care” value. Or, in the case of a non-applicable method, it becomes a null operation. Several additional text interfaces were added in MSAA 2.0. Unfortunately, AT technologies currently supply very limited support for MSAA 2.0; Eclipse supplies none at all.

In contrast, the GNOME Accessibility Project uses a more object-oriented approach that provides more specialized interfaces for a variety of UI elements. GAP defines a collection of about a dozen accessibility interfaces in an accessibility tool kit (ATK). Each UI element provides accessibility services by implementing one or more of these interfaces, as appropriate for the specialized behavior of that widget. This yields a richer feature set that an AT can exploit than the set that MSAA provides.

The org.eclipse.swt.accessibility package was initially modeled as a single interface with the MSAA 1.3 level of capabilities (the MSAA 1.3 methods were actually partitioned into two interfaces — one for standard widgets and another for custom controls). Eclipse 3.0 added support for GNOME, which included mapping Eclipse’s MSAA-based architecture to work with GNOME.

With Eclipse, developers need not worry about differences in the underlying platforms’ accessibility APIs. All accessibility support flows through org.eclipse.swt.accessibility, which contains platform-specific code for talking to the various platforms’ accessibility APIs.

Now that we have covered the basic features and functions that make Eclipse suitable for creating accessible applications, next month’s article will explore specific code samples for creating accessible custom controls in Eclipse.

Appendix: Legal aspects of accessibility

The primary business motivation for developing accessible solutions is fundamental: Increasingly, you can’t do business at all without offering an accessible solution.

In 1998, the United States Congress amended the existing Rehabilitation Act to require federal agencies to make their electronic and information technology accessible to people with disabilities. Inaccessible technology interferes with an individual’s ability to obtain and use information quickly and easily. This part of the regulatory body is known as Section 508. Enforcement of this law began in June 2001. Similar laws are in effect, or will soon be in effect, in many other countries.

Section 508 was enacted to eliminate barriers in information technology, to make available new opportunities for people with disabilities, and to encourage development of technologies that will help achieve these goals. The law applies to federal agencies when they develop, procure, maintain, or use electronic and information technology. Under Section 508, agencies must give both disabled employees and members of the public a degree of access to information that is comparable to the degree of access available to others.

An agency can choose to seek an exception from Section 508 regulations on the following grounds:

  • National security: Electronic information technology that is used for a national security system.
  • Contractor: Electronic information technology acquired by a contractor incidental to a contract — i.e. any application or computer equipment used to develop an application to be used by the federal government.
  • Back room: Electronic information technology located in spaces frequented only by service personnel for maintenance, repair, or occasional monitoring of equipment. Examples may include servers, disk storage devices, tape storage devices, and connective devices associated with these items.
  • Undue burden: Electronic information technology that would impose an undue burden on the agency. Undue burden means there are circumstances that make it extremely expensive or difficult to comply.

In all cases, it is the agency, not the vendor or product, that must seek the exception, and only within a specific application deployment context. Exceptions are increasingly rare. A product deployed under an exception in one context might not be considered for exception in another. That is because a hardware or software user interface used only in a back room in one application may be used in a kiosk in another application, for example. The agency might decide to seek an exception for the first context, but almost certainly not for the latter. In addition, some agencies want to be in a position to hire a blind system administrator, for example. They want everything to be accessible and enabled for ATs such as screen readers.

In any case, agencies are increasingly unwilling to grant exceptions because of a growing number of lawsuits.

Accessibility provisions for Section 508 are included in every federal executive branch bid. If a government agency does not satisfy Section 508 requirements, then a complaint can be filed against that agency, exposing it to litigation. For these reasons, vendors that meet Section 508 requirements are at a significant competitive advantage.

Similar regulatory legislation is in the pipeline for many US state governments, and in European and Asian geographies. Furthermore, similar requirements have already started to cascade from the public sector into private industries.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s


%d bloggers like this: