Active, accessible, and compatible applications give programmers new tools to use software

The goal of active accessibility is to facilitate people with disabilities to use computers--for amplifiers, screen readers, and tactile mice. It can also be used to develop applications that drive other software, and in the end, its ability to simulate user input is especially appropriate for testing software development.

Starting from the basic concept of Active Accessibility, this article takes you to a test application software development process. You will see how this test program interacts with commonly used controls and other UI elements, and handles subsequent winevents.

Microsoft®active accessibility® is a relatively new technology (launched in May 1997), which provides procedural access to UI elements by providing an effective way to extract information from any UI element (version 1.0). With this functionality, programmers can get information about the UI elements to interact with them. For example, you can press a button from a program, select an item from a list, or pull down a combo box. Initially, the technique was designed to make it easier for defective people to use software (such as people with poor eyesight), but in fact it was more widely used, such as amplifiers, screen readers, and tactile mice.

Active accessibility can run in windows98® and windows2000®. To be used under windows95® (English) and Windows nt4.0® (service Pack 6 and above), you can install the Active Accessibility rdk and SDK, which can be downloaded from the following site: http:// Msdn.microsoft.com/isapi/gomscom.asp? target=/enable/msaa/.

Additional information about Active Accessibility can also be found at this site.

The essence of Active accessibility makes it very suitable for designing programs that drive other software products. A class of programs that can make good use of Active accessibility is a test program. Another class might be a program that performs a series of user-defined keyboard and mouse input for state confirmation of UI elements-for example, a Windows media™ player that automatically responds to the Windows Media Player error message, thereby continuously trying to connect to A busy server program, this automatic response includes closing the dialog box, clicking the appropriate menu and continuing the interrupted connection process.

There are two types of active Accessibility-related programs: Programs that are compatible with active Accessibility and manipulate their tools. This paper studies the latter type: developing Active Accessibility tools to control other software products. As a focus, I'll focus on the development of test programs. These are not only useful, but they show almost all of the features of Active accessibility.

Active Accessibility Basics

The main idea of Active accessibility is to provide the ability to programmatically access UI elements to get information about these elements. The UI elements that support this feature are said to be accessible. In most cases, this means that a UI element supports the IAccessible interface. You can also say that in an active Accessibility world, an accessible UI element can be represented as a iaccessible interface.

Whenever you need information about an element, perform an action on it, or use Active Accessibility to do something else, you only need to refer to the element by using a method or attribute that represents the IAccessible interface for that element. Later, I'll explain how a IAccessible interface/child ID pair represents a UI element. Now, let's briefly focus on the IAccessible interface.

There are several ways to get pointers that represent an IAccessible interface that can access UI elements. The most common approach is to use a function provided by active Accessibility, such as Accessibleobjectfrompoint, Accessibleobjectfromwindow, and so on, or Use IAccessible supported methods, such as Get_accchild,get_accparent. These features and methods are described in detail later.

The IAccessible interface supports attributes that allow you to get information about each UI element, and the most important attributes for the test software are name, role, and state. Most of them will be described by examples. Let's take a look at Windows NT 4.0 Windows Explorer find: All file dialogs are shown in Figure 1, including a combo list box labeled "Look in:", whose name looks in:, the role is ComboBox, and the state is visible. The state of the UI element reflects the current state of the element.

Figure 1 The IAccessible Example