Visual: Common, Age, Large Fonts, High Contrast, Magnification, Screen Reader Motor & Speech: Mild -> Serious, Ignore False Activation, Specialized or Alternative Input Devices Synthetic Speech Hearing: Mild -> Serious, Subtitles Cognitive: Reading disorders, Comprehension & Composition Difficulties Speech Recognition Text Highlighting, Careful UI Design, Symbols & Pictures.
CSPI: The library for C bindings Pyatspi:The Python bindings atk-bridge: The bridges, of course, need to understand both sides of what it being bridged; so atk-bridge must link to both ATK and AT-SPI. Registryd: Daemon
application layer includes productivity software, desktop tools, window manager, panel, etc; these are the same apps found outside ‘accessibility enabled’ environments. Also included in the ‘application layer’ are the GUI toolkits and the APIs necessary to provide accessibility info to the rest of the subsystem. Those APIs may vary among applications and toolkits (i.e. Java, GTK+, mozilla, OpenOffice) but they give adequate information to allow bridging to the common layers below. infrastructure includes what we sometimes call the “accessibility subsystem” and is what people sometimes just call “AT-SPI”. We usually use the name “AT-SPI” more specifically to refer only to the software interfaces and implementations contained in the “AT-SPI” module; either way, the AT-SPI packages are key parts of the infrastructure layer. The infrastructure layer is what enables assistive technologies to interact consistently with different applications. assistive (or adaptive) technologies are the ‘adapter’ programs that help the user operate desktop and apps. Examples: GOK, Orca, dasher Q: are features like StickyKeys assistive technologies? A: It depends who you ask; for our purposes we will call them accessibility utilities or platform accessibility features, and use “AT” to refer to programs that form a direct interface between the end user and the desktop, such as Screen Readers and alternative input systems.
We can divide the infrastructure layer into “bridge code” and AT-SPI; the bridging code connects the applications with the AT-SPI subsystem and therefore can be considered part of the infrastructure. Bridges take accessibility support information (services, events) from within the application and converts it to a common format (in this case, the AT-SPI protocol). Examples: java-access-bridge for GNOME; libatk-bridge. Bridges are important because: Applications on the desktop may implement similar features with a wide variety of code: Applications are written in different languages (C, Java, python, etc.) and may use different b“GUI toolkits” to create their interface components (GTK+, Java/Swing, mozilla-gecko, OpenOffice). Their object models and internal APIs may be very different from one another (Gobject, UNO, mozilla) This information needs to be shared or “exported” in a common ABI and via a common IPC protocol. We refer to the code that converts to and from the common format as “bridging” code.
Bridges also listen to application events, for instance AtkObject events which are implemented as Gsignals, and convert them into the appropriate AT-SPI event notifications. Events may give the AT some information about a change which has occurred in an application, but in many cases the AT needs to make API calls in response to an event in order to update the information it presents to the user. For instance, if focus moves to a new widget, speech and/or braille output may needed to inform the user of this change and in order to create a useful presentation of the newly focused object for the user (either as a spoken words or braille dots); alternatively if GOK is being used and a menu is focused or pops up, GOK may wish to traverse this menu in order to present the new choices to the user as a set of selectable “GOK Buttons”.
GNOME applications implement an in-process accessibility API called ATK. This is ‘bridged’ to the common AT-SPI layer by the ATK-bridge module. Atk-bridge exports ATK information via AT-SPI – it knows and understands the ATK API, but it doesn't know anything about specific applications or even anything about gtk+.
GAIL hooks into ATK and implements ATK interfaces on behalf of GTK+. GAIL knows about ATK and GTK+, but neither ATK nor GTK+ know about GAIL. GAIL is dynamically loaded via GTK_MODULES The ATK implementations for the GTK+ widget set are provided by an extermal library called GAIL (or libgail). It is external for mostly historical reasons, and partly in order to allow alternate implementations to be loaded by specialized applications. In the diagram above, note that GAIL gets information from GTK+ via public GTK+ API, and uses that information to fulfill the ATK interfaces on behalf of those widgets. For instance the atk-bridge calls ATK API, but the ATK call is redirected through code in libgail which in turn uses gtk+ API calls to provide the corresponding information.
Swing defines a java-specific accessibility API in javax.accessibility The end result is AT-SPI, just as for GNOME apps (interoperability). OpenOffice.org have an internal UNO Accessibility API. Until recently they bridged internally to javax.accessibility; now they bridge to ATK. Java ATK Wrapper
GNOME Accessibility & Automation Testing A brief introduction to use GNOME Accessibility to do automation test Ray Wang Software Engineer Novell / firstname.lastname@example.org
Unpublished Work of Novell, Inc. All Rights Reserved. This work is an unpublished work and contains confidential, proprietary, and trade secret information of Novell, Inc. Access to this work is restricted to Novell employees who have a need to know to perform tasks within the scope of their assignments. No part of this work may be practiced, performed, copied, distributed, revised, modified, translated, abridged, condensed, expanded, collected, or adapted without the prior written consent of Novell, Inc. Any use or exploitation of this work without authorization could subject the perpetrator to criminal and civil liability. General Disclaimer This document is not to be construed as a promise by any participating company to develop, deliver, or market a product. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. Novell, Inc. makes no representations or warranties with respect to the contents of this document, and specifically disclaims any express or implied warranties of merchantability or fitness for any particular purpose. The development, release, and timing of features or functionality described for Novell products remains at the sole discretion of Novell. Further, Novell, Inc. reserves the right to revise this document and to make changes to its content, at any time, without obligation to notify any person or entity of such revisions or changes. All Novell marks referenced in this presentation are trademarks or registered trademarks of Novell, Inc. in the United States and other countries. All third-party trademarks are the property of their respective owners.