Accessibility APIs | Accessibility
Standards Based Development
oss and other platforms provide a set of interface to expose information about objects and events to ats. ats use the interfaces to gather information and interact with those widgets.
jaapiJava Accessibility api
jaapi allows Java developers to easily create Java applications that are accessible to persons with disabilities. Accessible Java applications are compatible with ats (screen readers, speech recognition systems, and refreshable braille devices.
Accessibility for the Java technology developer, means building the services and support into an application that enable people with disabilities to use the software. Java ats are implemented in the Java Foundation Classes (jfc) and they comprise two separate packages: Java Accessibility api and Java Accessibility Utilities.
Java Access Bridge for Windows makes it possible for a Windows based at to get at and interact with the Java Accessibility api. The Java Accessibility api is implemented in the jfc Project Swing user interface components.
References and Resources
msaa (Microsoft Active Accessibility)
msaa is a COM-based technology that improves the way accessibility aids work with applications running on Windows. It provides dynamic-link libraries that are incorporated into the operating system as well as a COM interface and application programming elements that provide reliable methods for exposing information about user interface elements.
msaa, Extensions, and How They Tie-in Together
msaa was Microsoft's first Accessibility api for Windows; it was insufficient to do ria upon its release, and also had/has deficiencies, which led browser vendors to change their implementation(s) slightly to work around msaas shortcomings.
Extensions added to msaa caused its implementation to vary slightly to accomodate them...essentially in order to test a "platform implementation", it is required to test msaa with the extension in order to meet compliance with the aria specification. msaa has two implementations, listed below:
- MSAA+IA2
MSAA based on the Windows COM (Component Object Model) based broker model that an AT can use ask the MSAA accessibility information from. IA2 is an extension to it. IA2 provides special Table interfaces, relationships, extended roles and states and object attributes as an example. This is implemented on both Firefox and Chrome.
- MSAA+UIAExpress
This uses a slightly different implementation of MSAA and something called UIAExpress. UIA is divided into a provider side (application side) and a client side (AT) API. Bridging technology maps both MSAA and UIAExpress (provider side) to a client side API. To get the information COM provides the inter process communication transort layer for MSAA and the bridge provides the inter process communication on the client side to get information from the provider side implementation. It should also be noted that Windows also bridges between MSAA and the UIA Client side API. Unfortunately, not all information is bridged to the UIA client side for IE. So, in order to get access to the necessary information you will see that the mapping tables use a combination of MSAA information and UIA Client side API interfaces to get the data.
uia would require a full client-side implementation of ie; ideally, both client-side and server-side are full implementations of client-side and server-side interfaces. Logistically, this poses a problem, because ideally you would want to have at/abbr>s that are fully dependent on uia to truly exercise it. This (so far) has not been the case, as legacy at vendors primarily used the dom, while sprinkling in bits and pieces of msaa, uia, and uia Express to gain access to ie. Narrator is the lone exception here as it does not, however the rest do because they have had to support older versions of ie throughout their software lifetime. One example is supporting ie6, which only provided dom and msaa support and gaps in the bridge. Consequently, there are also gaps in uia's implementation as well, which is there are many msaa uia client-side interfaces being used as the normative reference to accessing the ie platform.
msaa and extension api combination should be considered a single platform implementation as msaa cannot be taken on its own and because of its varied implementations, it cannot be treated as a normative platform implementation by itself.
Mac OS X Accessibility Protocol (AXAP)
All Cocoa applications can and should be accessible to users with disabilities. The process of making an application accessible is called access enabling. In Cocoa applications, accessible is achieved by user interface classes adopting the NSAccessibility informal protocol. Because standard Cocoa controls and views automatically adopt the NSAccessibility protocol, there is very little you have to do to access enable your application if you rely only on standard control and view objects.
If your application implements custom controls or views, however, you need to provide additional accessibility information to make your application completely accessible.
This topic discusses how Cocoa implements accessibility and describes specific tasks you need to perform to access enable your application.
atk - Gnome Accessibility Toolkit
atk provides the set of accessibility interfaces that are implemented by other toolkits and applications. Using the atk interfaces, accessibility tools have full access to view and control running applications.
IAccessible2 (ia2)
ia2 is an accessibility api which complements Microsoft's earlier work on msaa. This api fills critical accessibility api gaps in the msaa offering. ia2 was created out of necessity to produce a usable and accessible odf based office suite for the Commonwealth of Massachusetts. ia2 is an engineered accessibility interface allowing application developers to leverage their investment in msaa while also providing an at access to rich document applications such as the IBM Workplace productivity editors and web browsers such as Firefox. The additional functionality includes support for rich text, tables, spreadsheets, Web 2.0 applications, and other large mainstream applications.
aria + Accessibility apis
When aria is added to a document, the browser detects the aria attribute and updates the information within its accessibility api to reflect what the aria is supposed to convey. The screen reader then queries the browsers's accessibility api (per usual), rendering the content in the Virtual Buffer using the updated information. So placing role="button" like so:
<a role="button" href="#">Some Link</a>
The browsers's accessibility api convey's that the element is a button and the screen reader will display the element as a button, which will appear in the Form Field list in JAWS as though it were a form field, and can be navigated using the "b" and "shift+b" commands to jump between buttons on the page.
Note: it's important to understand the above because aria only changes the information in the accessibility api, not the element in the browser itself.
Browser Differences
Accessibility apis across browsers differ, as does aria support within each (YAY!!!). Specifically:
- Windows
- Accessibility apis for ie is implemented using msaa and uia
- Accessibility apis for Firefox is implemented using msaa and ia2
- Accessibility apis for Chrome is implemented using msaa and ia2
- Mac
- Accessibility apis for Safari is implemented using Ax/uIA
- Linux
- Accessibility apis is implemented using the Assistive Technology-Service Provider Interface (at-sp) and ia2
References and Resources
http://www.blackberry.com/developers/docs/6.0.0api/net/rim/device/api/ui/accessibility/package-summary.html" title="BlackBerry Accessibility API">Accessibility api
- Microsoft Active Accessibility (msaa)
- IAccessible2
- User Interface Automation (uia)
- Linux Accessibility Toolkit (atk) and Assistive Technology - Service Provider Interface (at-spi)
- Mac OS X Accessibility Protocol
Platform accessibility apis are used by at's for interactive ui elements; for static web documents, at's simply use the dom.
Expose html Features Not Directly Mapped to a11u api Properties
Note: there is not a one to one relationship between features and platform accessibility apis; when html roles, states, and properties do not directly map to an accessibility api, a method can be used to expose a text string, expose the undefined features.
IAccessible2 and atk use object attributes to expose semantics not directly supported in the apis. Object attributes are loosely specified name-value pairs, which are very flexible for exposing things when there is no specific interface in an accessibility api. For example, currently the header element can be exposed via an object attribute (header role="header because accessibility apis have no such role available.
Mac OS X Accessibility Protocol makes all getters simple name-value pairs, and new semantics can be exposed whenever necessary.
html to Platform Accessibility apis Implementation Guide
Microsoft Active Accessibility (msaa)
msaa is a technology that improves the way programs/operating system work with accessibility aids. msaa enables developers to build programs more compatible with accessibility aids. Active Accessibility provides a standard way for accessibilty aids to get information about user interface elements, and for programs to expose that information to the aids. Active Accessibility is an underlying technology and is invisible to users. Active Accessibility provides the following individual pieces of information:
- Type of object
- Name of object
- Location of object
- Current state of object
Active Accessibility also provides:
- Notification of change in user interface via Windows Events
- Notification of change in user interface via Navigation (Spatial and Logical)
Active Accessibility is a com-based technology that provides dynamic-link libraries that are incorporated into the os as well as a com interface and api elements, providing reliable methods for exposing information about ui elements.
IAccessible is the Active Accessibility com interface; it exposes methods and properties that make a user interface element and its children accessible to client applications.
Microsoft Active Accessibility (Windows)
ui Automation Framework
Microsoft ui Automation is an accessibility framework that enables Windows applications to provide and consume programmatic information about uis. It provides programmatic access to most ui elements on the desktop. It enables assistive technology products, such as screen readers, to provide information about the ui to end users and to manipulate the ui by means other than standard input. ui Automation also allows automated test scripts to interact with the ui.
By using ui Automation and following accessible design practices, developers can make applications running on Windows more accessible to many people with vision, hearing, or motion disabilities. Also, ui Automation is specifically designed to provide robust functionality for automated testing scenarios.
Microsoft ui Automation is the new accessibility framework for Microsoft Windows. It addresses the needs of assistive technology products and automated test frameworks by providing programmatic access to information about the ui. In addition, ui Automation enables control and application developers to make their products accessible.
References and Resources
uia (ui Automation)
uia is an api for ui accessibility designed to help at products interact with standard and custom ui elements of an application (or operating system) as well as to access, identify, and manipulate an application's ui elements.
uia is similar to msaa in that it provides a means for exposing and collecting information about user interface elements and controls to support user interface accessibility and software test automation. However, uia is a newer technology that provides a much richer object model than msaa, and is compatible with both Win32 and the .NET Frameowkr. uia was designed to be cross-platform and not just stuck on Windows. For controls and frameworks written from scratch, uia is recommended. msaa is handy for relatively simple controls, the technology doesn't support the complexity of modern user interfaces.
The current and latest specification of uia is found as part of the Microsoft ui Automation Community Promise Specification, also known as the Microsoft Open Specification Promise (osp).
The
uia specification is an advanced accessibility framework, developed by Microsoft, and released to the community including an irrevocable pledge of patent rights for anyone implementing the specification.
IAccessible2
IAccessible2 is an open-source alternative to Microsoft's IAccessible; IAccesible2 is an accessibility api for Windows applications.
User Interface Automation (uia)
ui Automation is an accessibility framework available on all operating systems that support Windows Presentation Foundation and replaces Microsoft Active Accessibility. ui Automation provides programmatic access to most desktop user interface elements, enabling assistive technology products such as screen readers to provide information about the ui to end users and to manipulate the ui by means other than standard input.
ui Automation allows automated test scripting to interact with the ui. Client applications can be written with the assurance that they will work on multiple frameworks because the ui Automation core masks any differences in the frameworks that underlie various pieces of ui. For example, the Content property of a wpf button, the Caption property of a Win32 button, and the alt attribute of an html img are all mapped to a single property, Name, in the ui Automation view.
ui Automation provides full functionality in Windows Vista, Microsoft Windows XP, and Windows Server 2003. There is some support for Microsoft Active Accessibility client applications, through a built-in bridging service.
Linux Accessibility Toolkit (atk) and Assistive Technology - Service Provider Interface (at-spi)
The Accessibility Toolkit (atk allows programmers to use common GNOME accessibility features to make GNOME applications more accessible.
The Assistive Technology Service Provider Interface (at-spi) uses native accessibility apis, providing toolkit-neutral ways of facilitating accessibility in applications. at-spi can also be used for automated testing of user interfaces (with tools like the Linux Desktop Testing Project and Dogtail).
atk//at-spi (Linux Accessibility Toolkit and Assistive Technology - Service Provider Interface)
Mac OS X Accessibility Protocol
The Mac OS X Accessibility Protocol is Apple's accessibility framework, providing the accessibility protocol that both Carbon and Cocoa frameworks implement to allow applications to represent themselves to assistive applications and assistive technologies. It also includes apis that assistive applications can use to drive the ui of another application running in Mac OS X.
The Mac OS X Accessibility Protocol
html to Platform Accessibilty apis Implentation Guide
User Interface Automation (uia)
Linux Accessibility Toolkit (atk) and Assistive Technology - Service Provider Interface (at-spi)
Mac OS X Accessibility Protocol
header element can be exposed via an object attribute (header role="header because accessibility apis have no such role available.Content property of a wpf button, the Caption property of a Win32 button, and the alt attribute of an html img are all mapped to a single property, Name, in the ui Automation view.ui Automation Fundamentals
Microsoft ui Automation enables assistive technology applications and automated testing tools to interact with the ui controls of other applications. This section explains the fundamental concepts that ui Automation is based on.
The ui Automation API is in two parts. One part is used by ui Automation provider applications, and the other is used by ui Automation client applications. The provider API enables developers of Microsoft Win32 custom control and other control frameworks to expose those controls to ui Automation and make them visible to client applications. The client API enables applications to interact with controls in other applications and retrieve information about them.
Platforms
iOS
