Notes: AT-SPI2 now includes AT-side C bindings with an API friendly to gobject-introspection but not compatible with the original CSPI library. It probably makes sense in the long term to port CSPI applications to libatspi. However, it should be fairly straight-forward to write a compatibility layer on top of libatspi, so it may be desirable to do so.

There are a number of cspi consumers (also listed on this page):

LDTP - LDTPv2 migrates LDTP away from CSPI to pyatspi. With this, it can operate in both the CORBA and D-Bus environments.

GOK - GOK is the heaviest user of CSPI. There are no plans or resources to port GOK to D-Bus.

BrlTTY - while not a GNOME project, BrlTTY is used by Orca. BrlTTY also provides direct interaction with AT-SPI, and has been ported to use both CSPI/CORBA and D-Bus for AT-SPI.

Status: 24-Mar-2010 - at the Accessibility/Hackfest2010 meeting on GNOME3, the GNOME accessibility team decided it is OK to drop CSPI for GNOME3. It's not desirable, but there are no resources to do the work. GOK is the component that will be adversely effected, but we will look to Caribou and other keyboard solutions (e.g., OnBoard) to supplant GOK. If there are any GOK users, we will recommend they stay with GNOME 2.30 or work with their distribution to include the CORBA a11y stack alongside the GNOME 3 packages.

libgail-gnome (drop for GNOME3)

Risk level: high

Work needed/remaining: find all uses of libgail-gnome and replace them with the ATK "plug and socket" API. These include Evolution and gnome-panel.

Notes: ATK also has the new plug and socket API to denote out of process accessibles and is implemented for AT-SPI/D-Bus only. This may be a solution to help replace libgail-gnome. See https://bugzilla.gnome.org/show_bug.cgi?id=601552. LiYuan - will help us with the details of where libgail-gnome is used and help shepherd the replacement of libgail-gnome usage with the ATK plug and socket API's.

Status: 20-Jan-2011 - Since panel-applets will not be ported to gnome-shell, Evolution is the only risk now.

Assistive Technologies

New Universal Access Preferences UI

Risk level: high

Work needed/remaining: implement, test, and make sure assistive technologies behave properly to changes in gconf settings.

Notes: the main workings of the new Universal Access Preferences UI will be to modify gconf settings. These settings may be listened for by *.desktop files with autostart settings, but they may also need to be listened for by assistive technologies (e.g., a running Orca process needs to acknowledge changes to speech settings). So, the work extends beyond just the GUI and needs to be coordinated with other modules in GNOME.

Status: 24-Mar-2010 - JonMcCann is taking a stab at implementing the new UI.

Status: 04-Oct-2010 - We don't know who is working on it, send a mail to key contacts?

Notes: While gnome-panel itself tends to do well with accessibility, there are issues with items inside it, both with the CORBA and D-Bus versions of the AT-SPI. These include problems with things such as the volume control applet, notification items, etc. - some regressions seem to have taken place since GNOME 2.28. gnome-panel needs further testing and we need to identify and resolve these issues.

Status: 24-Mar-2010 - still unsure where things are breaking. LiYuan will dig into this.

It is done? Ask Fernando Herrera and Carlos Garcia.

Medium Risk

Accessibility Stack

at-spi2-registryd (D-Bus)

Risk level: medium

Work needed/remaining: debugging, testing and performance of the D-Bus version

Purpose: provides the rendezvous point between GUI applications and assistive technologies. It is a means for GUIs to register themselves with the AT-SPI and for assistive technologies to discover running applications and register listeners for AT-SPI events.

Status: 24-Mar-2010 - Some work needs to be done on the activation of the registry upon login -- things seem to hang unexpectedly sometimes, more often on a slower machine (i.e., netbook) than faster machines. The registryd can be activated different ways -- D-bus activation and the *.desktop file -- timing issues in other areas may end up ticking both these methods and might be a potential source for the hang. (19-Jan-2011- need to test whether all of this is still happening.)

pyatspi2 (D-Bus)

Risk level: medium

Work needed/remaining: debugging, testing and performance of the D-Bus version

Notes: consumers of the Python bindings should not know the difference between the CORBA and D-Bus versions. That is, they should be able to still "import pyatspi" and function without code modification. See AccessibilityCORBAToDBusMapping for more information on how this is managed.

need to start working on using it with the Orca regression test suite as a means to help test and harden the implementation. Testing with LDTPv2 test suites will also be very useful.

Status: 19-Jan-2011 - Performance is significantly improved with the new gobject-introspection-based pyatspi2 using libatspi as a back end and direct dbus connections. Works best with pygobject newer than 2.27.0; until recently, there were memory leaks and a bug which made enums very slow. More testing is needed; Orca is generally usable with Firefox and pyatspi2, and performance seems similar to AT-SPI-CORBA, but there are some bugs. For instance, Orca reports that text is being unselected when it is being selected and may sometimes traceback when it tries to process an event from an application that has gone away. Exceptions are not currently equivalent to AT-SPI-CORBA exceptions (need to determine if there is a good way to associate particular exceptions with particular gerrors), which has the potential to cause regressions.

Notes: there is support in the other at-spi2 components to fall back to the session bus if this bus is not available. This might be a source of timing issues if it is assumed that the accessibility bus will be available as soon as the command to launch it is run. There should be some gate put in place to make sure the accessibility bus is available before launching other things (e.g., the registryd and anything using the atk-bridge) try to connect to it.

Status: 19-Jan-2011 - need to investigate whether timing issues are still present; they likely are since nothing has been done specifically to address them.

atk-bridge (D-Bus)

Risk level: medium

Work needed/remaining: debugging, testing and performance of the D-Bus version

Purpose: dynamically-loaded GTK+ module that lives inside the GUI process and which talks to the ATK peers created by the toolkit's accessibility layer. It also communicates with consumers of the AT-SPI infrastructure, such as Orca and LDTP via some interprocess communication mechanism (i.e., CORBA or D-Bus, depending upon the bridge). Used by other toolkits as well (GTK+, Gecko, Uno, and the new Java ATK Wrapper)

Notes: the CORBA and D-Bus modules have identical names ("atk-bridge") because it is hardcoded in other external projects, such as Gecko and OpenOffice. Along with the rest of the infrastructure, the D-Bus form still needs testing. It has yet to pass the Orca regression test suite, for example, as of 24-Mar-2010. Note also that the Gecko toolkit seems to crash with the D-Bus bridge.

Status: 19-Jan-2011 - This is generally working, although it could use some more testing. Requires dbus-glib 0.90 or greater for direct dbus connections to be enabled; will disable if an older dbus-glib is found.

Notes: JAW is new and replaces JABG. Because it uses ATK, JAW is independent of whatever bridge is used to talk with external processes, allowing it to be shielded from changes in interprocess communication mechanism. With JAW, however, comes some issues because it loads the atk-bridge. Care needs to be taken to prevent mixed-toolkit environments from loading the atk-bridge more than once.

Status: 24-Mar-2010 - needs testing with Orca and other assistive technologies as well as a mix of Java-based applications.

Notes: the use of this appears to be limited to the old GDM and the Solaris screen saver. If so, we may just be able to let it go away. LiYuan, JeffCai, and BrianCameron will help confirm this is the case.

Status: 24-Mar-2010 - need to decide if this can go away or not.

Status: 04-Oct-2010 - we *really* need to decide if this can go away or not

Assistive Technologies

Accerciser

Purpose: Accerciser is an interactive Python accessibility explorer for the GNOME desktop. It uses AT-SPI to inspect and control widgets, allowing you to check if an application is providing correct information to assistive technologies and automated test frameworks.

Dasher

Notes: Dasher's exposure to CSPI seems rather limited and can be removed as a compile time option (search for GNOME_A11Y in the code). Without this support, WillieWalker believes Dasher may still function standalone and can be used to type text by cutting/pasting between the Dasher GUI and another text area, which is how many people use Dasher today in GNOME. Dasher also optionally uses gnome-speech (search for GNOME_SPEECH in the code), but it's not apparent how many users actually use this feature. So, if users do not mind using Dasher standalone without needing AT-SPI or speech support, it should be able to function fine.

Status: 24-Mar-2010 - Dasher can be compiled without AT-SPI and gnome-speech support. This may be an acceptable solution moving forward. PatrickWelche has also begun looking at calling D-Bus methods directly to get to the a11y stack.

Notes: CarlosDiogenes has created an initial stab at "D-Bus-izing" the gnome-mag API. Whatever API is developed, it should be common between gnome-mag and the GNOME Shell magnifier, and Orca needs to be modified to use it. We may consider opening a "GOPA-sized" grant for Carlos to do this work and implement the API for gnome-mag and GNOME Shell mag.

Status: 24-Mar-2010 - the D-Bus API needs to be finalized and agreed upon between gnome-mag and GNOME Shell. Orca needs porting to the D-Bus API. gnome-mag might need modification to allow for conditional compilation of CORBA vs. D-Bus and also whether the CORBA/D-Bus functionality should be simultaneously available or mutually exclusive.

Status: 03-Jun-2010 - CarlosDiogenes said that there are some pieces mising, but right now he can't work on it. Mail here, and he asked for a volunteer for that

It is important as the current GS-mag DBUS API definition is affected by this, as the idea is to have the same API in both.

GNOME Shell Toolkit

Risk level: medium

GNOME Shell also is creating its own toolkit based on NBTK/MX. Any additional widgets created here need to support ATK and also need to support keyboard navigation. GNOME Shell may end up using some form of mx (in theory, St and MX will be merge, "eventually")

Status

27-Mar-2011: GNOME Shell has now built-in accessibility support, with custom accessibility objects. So now, orca reacts with it. But it is still missing several labels and specific work. Lowering from high to medium, as the base is there.

The other aspect of magnification that needs work is the Common Magnifier Framework. The specification needs to be finalized, and it needs to be implemented by the GNOME Shell magnifier. The development of GNOME Shell Mag has followed this framework with respect to GSettings. Only the D-Bus aspect needs work.

Notes: See also bug 595507, which is where the initial work is described. Orca is being modified to work with the D-Bus API provided in the patches attached to the bug, but we need to align the D-Bus API with the gnome-mag work (and vice versa). We also need to resolve issues such as how/where to store persistent settings.

patch for inverse video, contrast, and brightness enhancements https://bugzilla.gnome.org/show_bug.cgi?id=639851 received preliminary review. The code was updated, bugs fixed, and a new patch was submitted. The functionality, however, will not be part of the GNOME 3.0 release.

Orca does not present all applications in GNOME 3. Investigate why, and if this has anything to do with when/how the registry is started/stopped.

Additional testing with AT-SPI2.

Determine what is required from the design team with respect to Orca's GUI.

Migrating to the new magnification API that will be shared between gnome-mag and the GNOME Shell magnifier and/or cause Orca to co-exist nicely with the multiple magnification solutions which exist. Doing the latter is what Joanmarie would like to see occur since the majority of users who require magnification do not require the functionality of a screen reader (i.e. speech and braille); just focus and caret tracking. Such a change will require the magnification solutions to implement focus and caret tracking.

Desktop Environment

Clutter/Cally

Risk level: medium

Clutter is a very low-level "super class" for making widgets. Alejandro Piñeiro Iglesias (API) is working on Cally.

Cally is basically the GAIL equivalent for Clutter and will help provide a building block for accessibility support in GNOME Shell. It is required to a proper configuration of Cally and atk-bridge on gnome-shell. It is also important the Cally ATK support itself. You can check Cally bugs here:

27-Mar-2011: last changes not still integrated on the master, you can see then on gitorious

The main issue right now it the incomplete AtkText implementation (lack of a gailutil equivalent)

GNOME Shell: Theming

Risk level: medium

GNOME Shell provides some level of theming for adjusting colors, fonts, etc. It is unclear, however, how or if this theming support will be connected to the general GNOME theming/appearance properties. Need to contact the GNOME Shell team about this. Alejandro Piñeiro Iglesias (API) may help with this as well.

Status

27-Mar-2011: Dan Winship (Gnome-shell developer) opened a bug related to this issue, not started yet

Notes: gdm is generally troublesome, but getting better. The work being done with the new Universal Access Preferences UI (see below) will help solve a lot of problems, but we need to make sure it works well with gdm and is easily accessed. While the work includes defining hot keys to enable/disable accessibility features, we're currently lacking the mouse gesture support that was in the old gdm. Missing mouse gestures may or may not be an issue; if we can get the MouseTweaks dwell applet enabled by default on the gdm panel, we might be fine without the old mouse gesture support.

Status: 02-Feb-2011 (provided by Brian Cameron via email): GDM seems to work reasonably well with accessibility. You can configure GDM to launch AT programs or change to an a11y theme, and this can be configured in a per-display basis. This seems to provide basic section 508 support. Remaining serious issues include:

There really isn't a good bootstrapping mechanism. How does a user turn on a11y if they can't use the computer without first turning on AT? Or if someone else uses their machine and turns of the login AT program, the user may not be able to turn it back on.

There has been talk of adding keybindings to launch AT programs. I think this would be a nicer way to help address this problem. However, some mechanism to launch programs for users who cannot use the keyboard would also be needed to avoid these sorts of issues.

No simple way to configure GDM features aside from turning them on in the GDM login GUI program itself. You can use gconftool-2 to turn on a11y features, but there is no easy GUI program that helps users to configure the system the way they want.

Not really a GDM issue, but there isn't a great solution out there for how AT programs integrate with the lock screen program. Solutions that exist tend to be partial (e.g. for on-screen keyboard users but not blind users) and not easy to configure (e.g. they do not automagically figure out what AT programs to make available to the user).

Caret mode is implemented and works for pdf documents, but patches are waiting for approval. Pressing F7 change between caret mode and normal mode. In caret mode you can navigate throught text using normal keys, left, right, up and down, and select text pressing shift + normal movement keys.

AtkHypertext interface is implemented and patches are waiting for approval. It's needed to test it more, but it seems to work.

Text attributes like font family aren't exposed in AtkText interface, but I'm (danigm) working on that and will be done soon.

Notes: Yeah! Because it is independent of the interprocess communication mechanism used, the ATK library remains relatively stable. Note that ATK also has a new plug and socket API to denote out of process accessibles and is implemented for AT-SPI/D-Bus only. This may be a solution to help replace libgail-gnome when moving to AT-SPI/D-Bus. See https://bugzilla.gnome.org/show_bug.cgi?id=601552.

Assistive Technologies

MouseTweaks Applet

Purpose: the MouseTweaks applet provides on screen interaction for enabling/disabling MouseTweaks via "dwellable" icon in the panel, and then provide a means to select click operations (e.g., single click, double click, right click, drag) once the feature is enabled.

Notes: GerdKohlberger and FrancescoFumanti have been working to make MouseTweaks current with the new GDM panel. Work needs to be done with GDM to enable this applet by default in the GDM panel (and perhaps the desktop panel). Not sure of the status of GNOME Shell panel support.

Status: 24-Mar-2010 - Gerd has finished the D-Bus port and the GDM panel support. We need to get this into the GDM panel by default. There are also a couple of open bugs with respect to mouse:button and mouse:abs/rel events in AT-SPI/D-Bus.

Desktop Environment

GNOME Shell: Keyboard Navigation

Risk level: low

GNOME Shell requires support keyboard navigation (e.g., arrowing, tabbing, etc.) for people who cannot use the mouse. This requires support directly inside GNOME Shell and/or the toolkit that GNOME Shell is using.

Bugzilla: There are several bugs on bugzilla tracking the different aspects of the keyboard navigation, most of them solved.

Status

27-Mar-2011: Dan Winship implemented key nav support at the ST toolkit level, and applied it on most of the views. Some bugs still pending, but in general gnome shell is mostly key nav accessible now

Resolved

Yelp 3

Notes: Yelp 3 is based on WebKitGtk whereas previous versions were based on Gecko. This necessitated much work in both WebKitGtk (implementing accessibility for basic documents) and in Orca (implementing support for WebKitGtk).