Microsoft Active Accessibility (MSAA) is an application programming interface (API) for user interface accessibility. MSAA was introduced as a platform add-on to Microsoft Windows 95 in 1997. MSAA is designed to help Assistive Technology (AT) products interact with standard and custom user interface (UI) elements of an application (or the operating system), as well as to access, identify, and manipulate an application's UI elements. AT products work with MSAA enabled applications in order to provide better access for individuals who have physical or cognitive difficulties, impairments, or disabilities. Some examples of AT products are screen readers for users with limited sight, on screen keyboards for users with limited physical access, or narrators for users with limited hearing. MSAA can also be used for automated testing tools, and computer-based training applications.
The current and latest specification of MSAA is found in part of Microsoft UI Automation Community Promise Specification.
Active Accessibility was initially referred to as OLE Accessibility [1] and this heritage is reflected in the naming of its binary components such as oleacc.dll
and the header file oleacc.h
which contains definitions and declarations. As part of Microsoft's ActiveX branding push in March 1996, OLE Accessibility was renamed ActiveX Accessibility (sometimes referred to as AXA) and presented as such at the Microsoft Professional Developers Conference in San Francisco, March 1996. Later, the ActiveX branding was reserved for internet-specific technologies, and ActiveX Accessibility became Active Accessibility and frequently shortened to MSAA.
MSAA was originally made available in April 1997 as part of the Microsoft Active Accessibility Software Developers Kit (SDK) version 1.0. The SDK packaged included documentation, programming libraries, sample source code, and a Re-Distributable Kit (RDK) for accessible technology vendors to include with their products. The RDK included updated operating system components for Microsoft Windows 95. Since Windows 98 and Windows NT 4.0 Service Pack 4, MSAA has been built-into all versions of the Windows platform, and has received periodic upgrades and patches over time.
Programmatic exposure for assistive technology applications on Windows has historically been provided through MSAA. However, newer applications are now using Microsoft UI Automation (UIA), which was introduced in Windows Vista and the .NET Framework 3.0.
The following Active Accessibility versions have been released: [2]
Version | Description |
---|---|
1.0 | Original add-on release for Windows 95. The RDK was supported only in the English version of the operating system. (1997) |
1.1 | Included in Windows 98. |
1.2.x | First revision of MSAA that was made available to both English and international versions of Windows. (1998) |
1.3.x | Additional support added for more languages. Introduced satellite DLL (oleaccrc.dll) for its international text resource library. Later the system components were integrated into Windows NT 4.0 Service Pack 6 and beyond, Windows 98, Windows 2000 and Windows Me. (1999) |
2.0 | First major revision of MSAA, adding support for Dynamic Annotation and MSAA Text. This version was integrated into Windows XP. Minor revisions have been made to the MSAA framework within subsequent versions of Windows. The 2.0 version of the RDK was made available to older platforms (Windows 95, 98, 2000, Me, NT) in 2003. (2000–2008) |
3.0 | The framework has become part of the Windows Automation API 3.0, which is integrated into the Windows platform accessibility API set by MSAA and UI Automation (UIA). Windows Automation API is included in Windows 7 and available for Windows Vista and XP (2009) |
The motivating factor behind the development of MSAA was to allow an available and seamless communication mechanism between the underlying operating system or applications and assistive technology products.
The programmatic goal of MSAA is to allow Windows controls to expose basic information, such as name, location on screen, or type of control, and state information such as visibility, enabled, or selected.
MSAA is based on the Component Object Model (COM). COM defines a mechanism for applications and operating systems to communicate.
Figure 1 shows a high-level architecture of MSAA.
Applications (e.g., word processor) are called Servers in MSAA because they provide, or serve, information about their user interfaces (UI). Accessibility tools (e.g., screen readers) are called Clients in MSAA because they consume and interact with UI information from an application.
The system component of the MSAA framework, Oleacc.dll, aids in the communication between accessibility tools (clients) and applications (servers). The code boundary indicates the programmatic boundaries between applications that provide UI accessibility information and accessibility tools that interact with the UI on behalf of users. The boundary can also be a process boundary when MSAA clients have their own process.
The UI is represented as a hierarchy of accessible objects; changes and actions are represented as WinEvents.
The accessible object is the central interface of MSAA, and is represented by an IAccessible COM interface and an integer ChildId. It allows applications to expose a tree structure that represents the structure of the UI. Each element of this tree exposes a set of properties and methods that allow the corresponding UI element to be manipulated. MSAA clients can access the programmatic UI information through a standard API.
MSAA communicates information by sending small chunks of information about elements of a program to the assistive technology object (AT). The four critical pieces of information on which the AT relies to help users interact with applications are an element's role, name, value, and state:
Microsoft provides a complete list of controls and their functions. [3]
Role information is based on the type of UI control with which a developer wants to interact. For example, if a developer is implementing a button that is clickable, the developer would select Pushbutton as the Role to implement. The following table shows an example list of MSAA Roles and their related descriptions.
Role | Description |
---|---|
ROLE_SYSTEM_APPLICATION | The object represents a main window for an application. |
ROLE_SYSTEM_BUTTONMENU | The object represents a button that drops down a menu. |
ROLE_SYSTEM_CARET | The object represents the system caret. |
ROLE_SYSTEM_DIALOG | The object represents a dialog box or message box. |
ROLE_SYSTEM_DOCUMENT | The object represents a document window. A document window is always contained within an application window. This role applies only to Multiple Document Interface (MDI) windows and refers to the object that contains the MDI title bar. |
ROLE_SYSTEM_GRAPHIC | The object represents a picture. |
ROLE_SYSTEM_LIST | The object represents a list box, allowing the user to select one or more items. |
ROLE_SYSTEM_MENUBAR | The object represents the menu bar (positioned beneath the title bar of a window) from which menus are selected by the user. |
ROLE_SYSTEM_PROGRESSBAR | The object represents a progress bar, dynamically showing the user the percent complete of an operation in progress. This control takes no user input. |
ROLE_SYSTEM_PUSHBUTTON | The object represents a push button control. |
ROLE_SYSTEM_RADIOBUTTON | The object represents an option button, also called a radio button. It is one of a group of mutually exclusive options. All objects sharing a single parent that have this attribute are assumed to be part of single mutually exclusive group. Use ROLE_SYSTEM_GROUPING objects to divide them into separate groups. |
ROLE_SYSTEM_SCROLLBAR | The object represents a vertical or horizontal scroll bar, which is part of the client area or used in a control. |
ROLE_SYSTEM_TITLEBAR | The object represents a title or caption bar for a window. |
ROLE_SYSTEM_TOOLBAR | The object represents a toolbar, which is a grouping of controls that provides easy access to frequently used features. |
ROLE_SYSTEM_WINDOW | The object represents the window frame, which contains child objects such as a title bar, client, and other objects contained in a window. In MSAA, this window object is often equivalent to the HWND object in Windows. |
The Names for elements in an application are assigned in the code by the developer. Many objects such as icons, menus, check boxes, combo boxes, and other controls have labels that are displayed to users. Any label that is displayed to users on a control (e.g., a button) is the default for the object's name property. Ensure the Name of the object makes sense to a user and describes the control properly. The Name property must not include the control role or type information, such as button or list, or it will conflict with the text from the role property (acquired from GetRoleText function of MSAA API).
Value is used when a developer wants to return information from objects in the form of a string. Value may be returned for objects where percentages, integers, textual or visual information is contained in the object. For example, the property values returned from scroll bar and trackbar accessible objects can indicate percentages in strings.
Not all objects have a Value assigned to them.
The State property describes an object's status at a moment in time. Microsoft Active Accessibility provides object state constants, defined in oleacc.h, that are combined to identify an object's state. If predefined state values are returned, clients use GetStateText to retrieve a localized string that describes the state. All objects support the State property.
Microsoft designed the Active Accessibility object model during and after the release of Windows 95. The model is based on roles, each role representing a type of a user interface element. These roles are limited to user interface elements in common use at the time. For example, there is no text object model to help assistive technologies deal split buttons which combine multiple UI elements into one. MSAA does not attempt to represent styled text such as markup text or rich text documents. While MSAA still has the Value property, it can host only simple, non-styled text in its value. At the time, it was felt that the Microsoft Text Object Model (MS-TOM) would be more appropriate for expressing the attributes of formatted text. However, MS-TOM's complexity and limited initial adoption outside of Microsoft hampered access to rich text.
Another limitation involves navigating the object model. MSAA represents the UI as a hierarchy of accessible objects in a manner similar to Windows' Window Manager. Clients navigate from one accessible object to another using the IAccessible::accNavigate method. However, servers implemented accNavigate in unpredictable ways and often not at all. Clients, however, must be able to deal with all approaches for any MSAA server. This ambiguity means extra work for client implementers, and the complexity can contribute to problems depending on the server implementations.
Being a COM-based binary interface, IAccessible is immutable and cannot be changed without creating another interface. The result is that you cannot expose new roles, behavior or properties through the existing IAccessible-based object model. While intended to be a common subset of information about base UI elements, it was found to be difficult to extend to include information about new interaction methods.
MSAA was initially available as an add-on to Windows 95. It has been integrated with all subsequent Windows versions.
Microsoft UI Automation (UIA): The successor to MSAA was User Interface Automation (UIA). However, since there are still MSAA based applications in existence, bridges are used to allow communication between UI Automation and MSAA applications. So information can be shared between the two APIs, an MSAA-to-UI Automation Proxy and UI Automation-to-MSAA Bridge were developed. The former is a component that consumes MSAA information and makes it available through the UI Automation client API. The latter enables client applications using MSAA access applications that implement UI Automation.
Accessible Rich Internet Applications (WAI-ARIA): There is a general mapping from ARIA attributes to MSAA properties. [4]
IAccessible2 : MSAA provides the roots of IAccessible2. IAccessible2 leverages the work done on MSAA, and adds additional functionality.
Windows Automation API: Starting with Windows 7, Microsoft is packaging its accessibility technologies under a framework called Windows Automation API. MSAA will be part of this framework.
Active Accessibility is available for developers in all versions of Windows since Windows 95. Since its original introduction, MSAA has been used as a way to add support for programmatic access to the UI for many business and consumer applications, including Microsoft Internet Explorer, Mozilla Firefox, Microsoft Office, etc. In addition to accessibility aids such as screen readers, screen magnifiers, Augmentative and Alternative Communication (AAC) devices, the technology has been used by Test automation software, such as QuickTest Pro, Functional Tester, and SilkTest.
More implementations of MSAA in applications and AT products can be found by searching on the Microsoft Accessibility sites or on the AT Information website. [5] [6] [7]
VBScript is an Active Scripting language developed by Microsoft that is modeled on Visual Basic. It allows Microsoft Windows system administrators to generate powerful tools for managing computers without error handling and with subroutines and other advanced programming constructs. It can give the user complete control over many aspects of their computing environment.
Visual Basic for Applications (VBA) is an implementation of Microsoft's event-driven programming language Visual Basic 6.0 built into most desktop Microsoft Office applications. Although based on pre-.NET Visual Basic, which is no longer supported or updated by Microsoft, the VBA implementation in Office continues to be updated to support new Office features. VBA is used for professional and end-user development due to its perceived ease-of-use, Office's vast installed userbase, and extensive legacy in business.
Computer accessibility refers to the accessibility of a computer system to all people, regardless of disability type or severity of impairment. The term accessibility is most often used in reference to specialized hardware or software, or a combination of both, designed to enable the use of a computer by a person with a disability or impairment. Computer accessibility often has direct positive effects on people with disabilities.
A screen reader is a form of assistive technology (AT) that renders text and image content as speech or braille output. Screen readers are essential to people who are blind, and are useful to people who are visually impaired, illiterate, or have a learning disability. Screen readers are software applications that attempt to convey what people with normal eyesight see on a display to their users via non-visual means, like text-to-speech, sound icons, or a braille device. They do this by applying a wide variety of techniques that include, for example, interacting with dedicated accessibility APIs, using various operating system features, and employing hooking techniques.
Windows Management Instrumentation (WMI) consists of a set of extensions to the Windows Driver Model that provides an operating system interface through which instrumented components provide information and notification. WMI is Microsoft's implementation of the Web-Based Enterprise Management (WBEM) and Common Information Model (CIM) standards from the Distributed Management Task Force (DMTF).
Windows Forms (WinForms) is a free and open-source graphical (GUI) class library included as a part of Microsoft .NET, .NET Framework or Mono, providing a platform to write client applications for desktop, laptop, and tablet PCs. While it is seen as a replacement for the earlier and more complex C++ based Microsoft Foundation Class Library, it does not offer a comparable paradigm and only acts as a platform for the user interface tier in a multi-tier solution.
Windows Presentation Foundation (WPF) is a free and open-source graphical subsystem originally developed by Microsoft for rendering user interfaces in Windows-based applications. WPF, previously known as "Avalon", was initially released as part of .NET Framework 3.0 in 2006. WPF uses DirectX and attempts to provide a consistent programming model for building applications. It separates the user interface from business logic, and resembles similar XML-oriented object models, such as those implemented in XUL and SVG.
Microsoft Data Access Components is a framework of interrelated Microsoft technologies that allows programmers a uniform and comprehensive way of developing applications that can access almost any data store. Its components include: ActiveX Data Objects (ADO), OLE DB, and Open Database Connectivity (ODBC). There have been several deprecated components as well, such as the Jet Database Engine, MSDASQL, and Remote Data Services (RDS). Some components have also become obsolete, such as the former Data Access Objects API and Remote Data Objects.
As the next version of Windows NT after Windows 2000, as well as the successor to Windows Me, Windows XP introduced many new features but it also removed some others.
Compared with previous versions of Microsoft Windows, features new to Windows Vista are very numerous, covering most aspects of the operating system, including additional management features, new aspects of security and safety, new I/O technologies, new networking features, and new technical features. Windows Vista also removed some others.
The Speech Application Programming Interface or SAPI is an API developed by Microsoft to allow the use of speech recognition and speech synthesis within Windows applications. To date, a number of versions of the API have been released, which have shipped either as part of a Speech SDK or as part of the Windows OS itself. Applications that use SAPI include Microsoft Office, Microsoft Agent and Microsoft Speech Server.
Microsoft Management Console (MMC) is a component of Microsoft Windows that provides system administrators and advanced users an interface for configuring and monitoring the system. It was first introduced in 1998 with the Option Pack for Windows NT 4.0 and later came pre-bundled with Windows 2000 and its successors.
In Microsoft Windows applications programming, OLE Automation is an inter-process communication mechanism created by Microsoft. It is based on a subset of Component Object Model (COM) that was intended for use by scripting languages – originally Visual Basic – but now is used by several languages on Windows. All automation objects are required to implement the IDispatch interface. It provides an infrastructure whereby applications called automation controllers can access and manipulate shared automation objects that are exported by other applications. It supersedes Dynamic Data Exchange (DDE), an older mechanism for applications to control one another. As with DDE, in OLE Automation the automation controller is the "client" and the application exporting the automation objects is the "server".
Live Connect is a collection of APIs and common controls that allow developers to have a deeper control and offers access to the core Windows Live services and data through open and easily accessible application programming interfaces (APIs). At MIX07, Microsoft's Senior Architect Danny Thorpe described:
[The Windows Live Platform] today can combine video, photos, contacts, maps, and search into web applications. Users can drop web controls into the web applications with just a few lines of JavaScript and be up and running in a matter of minutes, and they can dive a little deeper to access service APIs directly and define their own UI and process flow. Users have control over what applications can access their private data, and can revoke that access at any time.
NonVisual Desktop Access (NVDA) is a free and open-source, portable screen reader for Microsoft Windows. The project was started by Michael Curran in 2006.
IAccessible2 is an accessibility API for Microsoft Windows applications. Initially developed by IBM under the codename Project Missouri, IAccessible2 has been placed under the aegis of the Free Standards Group, now part of the Linux Foundation. It has been positioned as an alternative to Microsoft's new UI Automation API.
Microsoft UI Automation (UIA) is an application programming interface (API) that allows one to access, identify, and manipulate the user interface (UI) elements of another application.
Windows Vista has many significant new features compared with previous Microsoft Windows versions, covering most aspects of the operating system.
Wireless Zero Configuration (WZC), also known as Wireless Auto Configuration, or WLAN AutoConfig, is a wireless connection management utility included with Microsoft Windows XP and later operating systems as a service that dynamically selects a wireless network to connect to based on a user's preferences and various default settings. This can be used instead of, or in the absence of, a wireless network utility from the manufacturer of a computer's wireless networking device. The drivers for the wireless adapter query the NDIS Object IDs and pass the available network names (SSIDs) to the service. The service then lists them in the user interface on the Wireless Networks tab in the connection's Properties or in the Wireless Network Connection dialog box accessible from the notification area. A checked (debug) build version of the WZC service can be used by developers to obtain additional diagnostic and tracing information logged by the service.
Component Object Model (COM) is a binary-interface standard for software components introduced by Microsoft in 1993. It is used to enable inter-process communication object creation in a large range of programming languages. COM is the basis for several other Microsoft technologies and frameworks, including OLE, OLE Automation, Browser Helper Object, ActiveX, COM+, DCOM, the Windows shell, DirectX, UMDF and Windows Runtime. The essence of COM is a language-neutral way of implementing objects that can be used in environments different from the one in which they were created, even across machine boundaries. For well-authored components, COM allows reuse of objects with no knowledge of their internal implementation, as it forces component implementers to provide well-defined interfaces that are separated from the implementation. The different allocation semantics of languages are accommodated by making objects responsible for their own creation and destruction through reference-counting. Type conversion casting between different interfaces of an object is achieved through the QueryInterface
method. The preferred method of "inheritance" within COM is the creation of sub-objects to which method "calls" are delegated.