GNOME Bugzilla – Bug 519359
Define/implement an automated accessibility testing strategy
Last modified: 2014-11-13 20:41:28 UTC
We need to develop a clear accessibility test strategy/framework for GNOME and generate initial tests that use this strategy/framework. The main goal is to make sure the GNOME desktop as a whole provides compelling access via theming, keyboard access, assistive technologies, etc. The testing should provide automated tests that help identify and prevent regressions as early as possible. These tests can consist of non-runtime tests such as GLADE file linting as well as runtime tests that check for accessibility hierarchy and accessibility event issues in running applications (e.g., perhaps new assertions or targets to add to LDTP/Dogtail/Strongwind). In addition to this work, the leader of this needs to champion a culture of automated testing so that GNOME module maintainers understand the real benefit in maintaining and using a high-quality test library. Deliverables include the following: * The testing strategy/framework * Identification/implementation of how this will fit into a "make check" target * Tests that show how to verify accessibility support works for theming, keyboard navigation, and compelling access via the assistive technology suite of GNOME (e.g., Orca, GOK, Dasher, MouseTweaks, etc.). See also recent gnome-accessibility-list, desktop-devel-list, and GNOME Boston 2006 discussions on this topic: http://mail.gnome.org/archives/gnome-accessibility-list/2008-February/msg00071.html http://mail.gnome.org/archives/desktop-devel-list/2008-February/msg00103.html http://live.gnome.org/TestingUsingAtSpi
Since 90% of applications use stock GTK+ widgets, an automated test over a program like gtk-demo, while waiting for expected events would cover a lot of ground.
[Resetting QA Contact to newly introduced "at-spi-maint@gnome.bugs". Reason: So far it was impossible to watch changes in at-spi bug reports without following all the specific persons (Li Yuan, Bill Haneman, Jeff Wai, ...) and also their activity outside of at-spi reports. IMPORTANT: Anyone interested in following all bug activity (including all maintainers) must watch the "at-spi-maint@gnome.bugs" dummy user by adding it to the 'Users to watch' list under Preferences->Email preferences. This is also the default procedure nowadays in GNOME when setting up new products.]
[Mass-resetting default assignee, see bug 705890. Please reclaim this bug report by setting the assignee to yourself if you still plan to work on this. Thanks!]
I'm going to go ahead and close this because it concerns a very old version. Feel free to open a new bug if the problem persists.