Accessibility on by default

Status: completed

Description

<original text from the feature proposal sent to desktop-devel>

GNOME 3.4 shows improvement in the accessibility stack: in performance, stability and support of core applications like GNOME Shell [1][2]. Although part of this work consisted of improvingthe integration of the accessibility support within the toolkits (e.g. no more gail, but ATK implemention inGTK+), the accessibility framework is still relying on plugin loading based on the 'accessibility-toolkit' gsetting value.

During the last ATK/AT-SPI2 hackfest, we discussed that the next step would go a step further: 'accessibility-toolkit' would disappear, plugins would also disappear, and the accessibility support would be a integral part of GNOME toolkits and applications. As a result, accessibility support would receive more attention, both on runtime and on compile time, and more feedback would be received [3].

Although the hackfest answered some questions about how to proceed, there are others which remain. For instance, we want to drop the atk-bridge loading, but we still need to decide how to accomplish this. And there are other issues that would require our attention first, such as eliminating the need for toolkits to emit the key events (keysnooping).

So after a thread on gnome-accessibility-devel [5] and some chat on IRC, we think that for the moment it would be better to propose a compromise:just switch the default value of 'toolkit-accessibility" to true, in other words the accessibility support would be on by default. While a small change in terms of a "feature," it would result in more runtime testing (and feedback) for this cycle while we work on the unanswered questions for the next cycle. In the same way, if something goes wrong (like core app X crashing constantly and no solution), it would be easy to revert the changeprior to the end of the cycle.

• [1] http://blogs.gnome.org/mclasen/2012/03/27/tomorrows-gnome/

• [2] http://blogs.igalia.com/apinheiro/2012/03/30/gnome-3-4-finally-orcagnome3/

• [3] http://blogs.igalia.com/apinheiro/2012/01/24/atkat-spi2-hackfest-2012-days-2345/

• [4] http://blogs.igalia.com/apinheiro/2012/01/24/atkat-spi2-hackfest-2012-days-2345/

• [5] https://mail.gnome.org/archives/gnome-accessibility-devel/2012-April/msg00008.html

Owner

Alejandro Piñeiro

Involved Parties

Accessibility team

Affected modules: gtk, clutter, gnome-shell, at-spi2-atk

Current Status

The implementation plan has changed:

The original proposal was just changing the default value of 'toolkit-accessibility' to TRUE. But although the bridge would not register to events and start to emit DBUS messages unless some AT is listening, it is true that legacy apps using GTK2 or older ATK implementation doesn't have those stability/performance improvements that was part of the reasons this feature was proposed. In the same way, just loading a module (atk-bridge, that could not be installed at the moment) by default is still not a good solution (another hack over hack). So the solution to be implemented is librarify atk-bridge, and add a new dependency on the modules involved.

So:

• 'toolkit-accessibility' default value is still FALSE
• atk-bridge is not anymore a module, but a library
• gtk and gnome-shell calls atk_bridge_adaptor_init

That means that GTK3 apps and gnome-shell has the accessibility always on, and for legacy apps using GTK2, that will be still controlled by 'toolkit-accessibility'

All the discussion on Bug 677491

Other bugs involved:

• Bug 678051 Export atk-bridge as a library

• Bug 678095 Accessibility always on on GNOME Shell

• Bug 663256 Accessibility menu does not have "screen reader"

How to Help

Test the accessibility support of GNOME, specifically with Orca, in order to detect any possible crash/regression/performance loss.