ARCHIVED CONTENT
(2011 Proposals for Improving GNOME Accessibility)
NOTE: This page is being kept for historical purposes only. The content and proposals no longer apply in their current form due to changes and improvements which have been made in GNOME 3.x since this page was created.
Peformance Improvements
Summary:
The performance of the GNOME desktop with accessibility support enabled is reportedly significantly degraded -- even if no assistive technologies are actually being used. For this reason, the GNOME community has decided that accessibility support cannot be enabled by default and stated that we do not have an "accessibility story" to tell. Furthermore, the original inclusion of accessibility as a "feature" of GNOME 3.2 was since removed after the Release Team concluded it would not be possible to solve this issue in time for 3.2 and possibly not even in time for 3.4.
The Accessibility Team would like to see this issue solved much sooner than has been suggested: GNOME 3.6 is far too long a time to wait to "ensure that its software is usable for everyone, including people with disabilities." [1]
In order to ensure the desktop performance accessibility issues get addressed for all users in a timely fashion, the Accessibility Team would like to issue an RFP soliciting bids for a contractor to complete the work.
[1] http://www.gnome.org/about
Details:
The work has been separated in the following bids:
1. Full performance analysis identifying the impact of enabling accessibility support:
When no assistive technologies are being used.
When assistive technologies are being used.
2. A detailed, prioritized list of the specific sources/causes of the performance degradation problems identified in items 1.1 and 1.2, along with an estimation of the time required to address each.
3. The development of a performance regression test solution for key GNOME desktop technologies, including the accessibility libraries and core toolkits.
Estimated cost:
Parts 1+2: $15,000 USD
Part 3: $10,000 USD
GNOME Shell Magnifier track focus and caret
Summary:
GNOME Shell Magnifier does not track focus or the caret. As a result, GNOME Shell Magnifier users who prefer the keyboard must either regularly move the mouse to see the active area, or use Orca to cause the area of interest to be displayed by the magnifier. Screen magnification solutions in other platforms are able to track both focus and caret independently.
Ideally, GNOME Shell Magnifier should display the focused area and the caret (where applicable) on its own. For those users who require both magnification and speech output and/or braille, Orca and GNOME Shell Magnifier should happily coexist, each doing the jobs they are intended to do without interfering with one another.
While the project is summarily described as adding focus tracking to the magnifier, it is better described as two goals. The first goal is to design and implement a focus and caret tracking device that is independent of the magnifier. While the magnifier is likely the first consumer of the focus tracker, there are other applications that would make use of the tracker. An example is an onscreen keyboard (Caribou). As such, the focus tracker is a separate device independent of any client.
The second goal is to have the magnifier use the focus tracker in a way that matches how Orca currently drives the magnifier; that is, provide different tracking settings (e.g., centered vs. proportional), and a user interface so users can choose among the settings.
Details:
Some background: there is a proof of concept standalone app that shows how to track the focus and caret.
the app is written in Python.
it uses AT-SPI to detect changes in keyboard focus and changes in caret position
it uses D-Bus to drive the magnifier in terms of what to display.
1. (Investigative) Create a FocusCaretTracker object that runs within GNOME Shell
written in JavaScript and uses the JavaScript binding for AT-SPI.
does not use D-Bus to communicate with the magnifier, but calls it directly.
ultimately, replace this direct communication with a "callback" technique -- see step 2 below.
Pit fall:
the JavaScript/AT-SPI binding may not be as complete as Python's with respect to capturing focus and caret change events.
results in either a diversion to fix this, or ask the team responsible for the binding to fix it.
2. Modify FocusCaretTracker to use callbacks.
provide methods to allow other objects to attach a function that is invoked when a focus change event occurs.
e.g., the magnifier adds a callback to the FocusCaretTracker to be notified when the keyboard focus changes.
the FocusCaretTracker maintains a list of such callbacks.
when a focus change occurs, the callbacks are invoked.
FocusCaretTracker provides methods to remove callbacks.
thus, the focus tracker does not call upon, say, the magnifier directly, but allows the magnifier to attach a callback if it so desires.
Pit fall: possible synchronous vs. asynchronous callback issues here since they occur within an AT-SPI event processing "thread".
3. (User preferences) Provide support for different kinds of positioning.
Preferences include "centred", "proportional", and "push" positioning.
these are specific to the magnifier, and not part of the FocusCaretTracker.
there are separate preferences for focus tracking and for caret tracking.
gsettings-desktop-schemas: implement positioning settings as per gsettings spec.
gnome-control-center: implement dialog to allow user to modify these settings.
magnifier: make it sensitive to changes in these settings.
Estimated cost:
$11,200 CAD ($11,200.00 CAD = $11,335.17 USD 2011-09-15) < $11,400 USD