GNOME Accessibility Logo

GNOME Accessibility Team

Requirements and Proposed Two-Year Road Map

November 2010 - November 2012


The following outlines the areas of development needed to ensure that the GNOME Desktop not only remain accessible, but also continues to develop into a more compelling platform available to more people. It is admittedly an ambitious plan, but still one we think is achievable -- so long as the GNOME community and other stakeholders continue to allocate resources commensurate with the needs.


This road map is NOT everything we as a team hope and intend to achieve; it is merely those goals which are shared by us all. The individual modules that make up GNOME Accessibility each (should) have their own road maps which in many cases far exceed what is described here. You are encouraged to view these road maps as well:

Definitions Used in This Document

October 2010 - April 2011


Status: Mostly Completed (see notations below)

GNOME 3.0 is now scheduled for release in March 2011; 3.0.1 in April. There are a number of significant changes taking place which threaten the accessibility of the GNOME Desktop. The current areas of concern, along with the status of each area, is being tracked in detail. In summary:

Increased and Improved User and Developer Documentation

Status: Mostly Completed (see notations below)

Accessibility documentation for both end users and developers has historically been incomplete and not up-to-date. This makes GNOME accessibility less approachable to users, would-be contributors, new accessibility developers, and developers of other modules implementing accessibility support in their application or toolkit. We must:

In addition, Yelp 3.0 and Mallard allows documentation to be tagged and organized according to context and use case. Each Accessibility application team should:

Improved Regression Testing Tools for Applications and Toolkits

Status: Not completed

The Accessibility team spends a non-trivial amount of its time triaging and filing bugs introduced by changes in the applications and toolkits GNOME ATs provide access to. It would be much better if these regressions could be automatically detected when they are made so that the problematic changes are identified and not committed. A new Accessibility testing infrastructure, which will provide generic automated accessiblity tests as well as a core framework for commit-triggered running of tests within a test environment, is therefore being created.

Performance Evaluation and Improvement

Status: Not completed

Many users and developers complain frequently about performance with respect to GNOME accessibility, both the tools themselves (e.g. Orca) and the performance degradation seen in applications when accessibility support is enabled for the session -- even when no assistive technologies are being used. This latter issue is frequently cited as the cause for developers not enabling this support as well as for the community and distros being unwilling to enable this support by default.

April 2011 - April 2012

Note: Additional planning will occur once the accessibility team has a better understanding about what manpower and financial resources will be available to perform the work described here. With that understanding, we will be able to provide a better, and more specific, estimate regarding what can be accomplished in the first six-month period and what will wait until the second six months.

Bug Fixing

Status: In progress, but not completed

Despite the best efforts of the teams working on GNOME 3.0, there will undoubtedly be bugs which are not caught in time to make the GNOME 3.0 release. We will not fully know what all is broken until a significant number of GNOME users have worked with GNOME 3.0 on a regular basis. In addition, there are already a non-trivial number of accessibility bugs logged in GNOME's bugzilla, many of which are not bugs in accessibility modules, many of which have yet to be triaged, and many of which have been open for years. If we want to provide a truly compelling desktop environment, we need to fix these bugs.

Implement "Testing Days" for GNOME Accessibility

Status: Not completed

Accessibility testing in GNOME has historically been a "catch as catch can" effort, done primarily by members of the team as part of the work they are doing on their individual modules. As a result, we currently have gaps in our testing. It would be advantageous to organize and formalize our testing efforts and to involve the community.

Improved and Increased Access to Applications, Toolkits, and Environments

Status: Not completed

The Accessibility team would like to provide more compelling access to currently-supported modules and implement support for modules which are currently not supported due to problems with their accessibility implementation. This requires collaboration between our team and the teams whose applications and toolkits we would like to provide access to. It also requires that the teams with whom we wish to collaborate have the time (or other resources) to work with us.

Augmented and Consistently-Implemented Atk

Status: Not completed

Applications and toolkits do not all implement Atk consistently. This has a negative impact on the assistive technologies' ability to provide a consistent cross-application user experience. Even in applications and toolkits in which the Atk implementation is complete, the information obtained from a single event and/or object is not always sufficient for an AT client to proceed immediately; instead it is often necessary to perform further queries and make decisions based on heuristics rather than concrete data. This has a negative impact on both performance and reliability.

Alternative Input Devices: Needs Assessment/Study

Status: Not completed

GNOME has very few options for users who require alternative input device(s), including users with physical disabilities and users with learning disabilities. The Accessibility team lacks sufficient domain expertise in these areas to create a definitive list of user requirements from which our existing tools could be improved and "missing" tools created. Similarly, because we lack compelling solutions in these areas, we do not have an extensive user population providing us with feedback and requests. In order to ensure that the GNOME Desktop is an environment which is truly universally accessible, we need to provide solutions based on a detailed and accurate understanding of user needs in this area.

Optical Character Recognition (OCRFeeder) as an Assistive Technology

Status: Not completed

Optical Character Recognition can be an extremely valuable tool for accessing print materials, both for users who are blind and for users who have a print-related learning disability. OCRFeeder is the module best-suited for addressing this need in the GNOME Desktop, though it was never designed with this purpose in mind. Through the Guadalinfo Accessible projects from Andalucía, Spain, a number of improvements were made to enhance OCRFeeder's accessibility. A number of additional improvements would be helpful to make OCRFeeder a truly compelling tool for users who are blind. In addition, there are likely changes and new features which would make OCRFeeder a more compelling tool for users with learning disabilities.

June 2011 - June 2012


Status: Not completed but no longer relevant

Meego is the joining of Maemo and Moblin, targeted for mobile devices, netbooks, tablet computers etc. Both extensively use GNOME technologies. Although on the handset flavour it is intended to use Qt by default, recently the Foundation opened a public bid in order to ensure that gtk works on Meego Handset (specific flavour for smartphones).

This project has the potential to be a real competitor to Apple IOs (but more open) and to Android (but with more GNOME technologies), with two really big companies pushing for it, Intel and Nokia. In addition, because Meego will provide an infrastructure shared by a variety of devices, having Meego fully accessible would mean accessible smartphones, accessible netbooks, accessible set-top boxes, etc.

Therefore, the Accessibility team is interested in seeing if the current GNOME accessibility libraries can be ported to this platform. This project would encompass:

Please note that the projected dates for this work are especially tentative as they depend upon the porting of Gtk to Meego.

Create a Set of "Presentation" Libraries

Status: Not completed

Currently Orca is, for all intents and purposes, the only AT which presents on-screen information to the user in alternative formats. It is highly desirable for other applications to be able to perform similar functions independent of Orca. In addition, there are enhancements found in the ATs of other platforms which users find helpful and which GNOME lacks. The Accessibility team would therefore like to create a set of libraries which all applications (ATs and non-ATs alike) could use including:

October 2011 - October 2012

Note: Additional planning will occur once the accessibility team has a better understanding about what manpower and financial resources will be available to perform the work described here. With that understanding, we will be able to provide a better, and more specific, estimate regarding what can be accomplished in the first six-month period and what will wait until the second six months.

Speech Recognition as an Assistive Technology

Status: Not completed

There are a couple of solutions for speech recognition available to GNOME users: GNOME Voice Control and Vedics. Neither of these solutions seems to be under active development. In addition, each solution depends upon CSPI which currently has not been implemented as part of the D-Bus-based AT-SPI. If that issue is resolved, testing and additional development will be required to ensure it works with GNOME 3.0. If these issues are not resolved, and/or if the conclusion is reached that neither of these tools provide the needed support, a new solution will need to be created.

Based on the findings from that assessment, either:


Alternative Input Devices: Implementation

Status: Not completed

By April 2012 (and hopefully much sooner) we anticipate having completed a needs assessment/study to determine what alternative input devices, along with the corresponding software tools, will best address the needs of users with physical disabilities and users with learning disabilities. We also anticipate having had created, and received feedback on, prototype solutions. Armed with this information, we will formally implement the software-based solutions.

External Usability Reviews

Status: Not completed

The Accessibility team lacks expertise in the area of Human-computer interaction (HCI). The team would, therefore, like to engage the HCI community in the hopes of finding experts to conduct several (i.e. two or three) independent studies of the usability of our AT modules.

Given the number of planned changes in both the ATs and in the GNOME Desktop, some members of the Accessibility team feel it would be best to give the environment a chance to stabilize before these reviews are conducted. Alternatively, reviews can be conducted sooner as desired and as resources permit, but then follow-up reviews should still be conducted in FY2012 so that we can separate known, temporary "rough edges" from things we thought we finished but could/should have done differently.

Begin Implementation of Changes Identified from Usability Reviews

Status: Not completed

It is the hope of the Accessibility team to have at least some feedback from the aforementioned external usability reviews prior to October 2012. Based on this feedback, the appropriate module teams should work on implementing the recommended changes.

Accessibility/Roadmap (last edited 2011-11-28 19:07:30 by JoanmarieDiggs)