GNOME's accessibility efforts took a serious hit in 2010 when Oracle
acquired Sun and cut developer
jobs from Sun's Accessibility Program Office (APO). The APO had been
home to full-time developers working on GNOME accessibility components like
the Orca screen reader and the
Accessibility Toolkit ATK.
The GNOME Foundation is preparing a major accessibility push in 2012,
beginning with a fundraising campaign that will direct donations towards needed development tasks.
Because of the APO layoffs
and the amount of time and effort required to release GNOME 3.0, many of
the outstanding accessibility tasks were falling through the cracks. Some
modules and changes had to be dropped, and some bugs and new work had to be
back. GNOME held an accessibility hackfest in March 2010 to reorganize
Making 2012 the year of accessibility
Eventually, others in the GNOME ecosystem took up some of the slack, however, including open source consulting firm Igalia, and developers from other Sun/Oracle offices. In an effort to further accelerate development, the GNOME Foundation is making accessibility the focal point of a new fundraising campaign, run through the foundation's "Friends of GNOME" (FoG) program.
FoG allows individuals to make monetary donations in one-time or
recurring monthly amounts. The new FoG site highlights the importance of
accessibility, linking to a testimonial
from Robert Cole, an IT student with a significant visual impairment. It
also lists six
areas where the GNOME Accessibility Team wishes to target development
First, the team wants to alleviate the performance hit that comes with
running Orca or other assistive technologies, having noticed that sessions
slow down whenever the assistive technology component is running, even
if the application is not being used. Certainly some amount of overhead is
to be expected when running an application like Orca, but the noticeable
even-while-not-in-use performance degradation is frequently cited by
third-party developers as a reason for not adding ATK support to their
There are also three applications that need specific feature work. One
is adding cursor- and focus-tracking to GNOME Shell's built-in Magnifier,
so that users do not need to manually move the magnified region while
working. Another is adding awareness of document structure and formatting
to the Evince PDF reader and the Poppler library that powers it. This
amounts to making rich-text features available to a screen reader, so that
it could move between headings or simply announce structural markers and
formatting, rather than reading the text in "flat" form. A third is adding
accessibility features to WebKitGTK+, which is the HTML component used by
the GNOME help system and which may be incorporated into future versions of
the Evolution mail client. Finally, there are project maintenance tasks
needing work, such as improving accessibility regression-testing tools, and
fixing a list of outstanding GNOME 3 accessibility bugs.
Although that might sound like a long list, it still takes up only a fraction of the overall GNOME accessibility roadmap. GNOME Foundation Executive Director Karen Sandler said in an email that although the dates have slipped since the roadmap page was first written, its status information is current, and still reflects an up-to-date look at the project's accessibility progress.
One item from the roadmap will be the subject of an accessibility
hackfest to be held at Igalia's offices in A Coruña, Spain from
January 18-22, 2012: augmenting
ATK and ensuring that it is consistent across toolkits and
applications. ATK is a set of interfaces that toolkits implement to expose
the contents of GUI components in a standardized way, thus allowing
accessibility tools (like Orca) to read and manipulate them. Each GUI
toolkit — GTK+, Clutter, Mozilla's Gecko, etc. — builds its own
implementation of ATK. The trouble comes when they do not all implement
ATK in exactly the same way, such as emitting different signals for the
Orca maintainer Joanmarie Diggs, who is now an Igalia employee, said
that this inconsistency is
largely the result of lack of documentation of the accessibility
APIs. After all, one cannot expect cross-toolkit consistency if exactly
what is expected of them is not stated clearly and/or the documentation
leaves too much up to implementer interpretation. Nonetheless, the end
result of the inconsistencies is that an AT [Assistive Technology] such as
a screen reader must do
toolkit specific handling, which is less than ideal.
Improving the ATK documentation so that it serves as a better guide for developers is one of the hackfest's primary goals. Developers from the GTK+, Qt, and Mozilla projects are already confirmed to attend. Qt, it should be noted, does not use ATK directly, but rather interfaces directly to the underlying Assistive Technology Service Provider Interface (AT-SPI).
The other side of the ATK-augmentation coin is seeing where it makes sense to extend the ATK API itself. The roadmap document lists several issues, including adding additional information to certain events and objects. Diggs gave three examples: selection, text attributes, and table cells. Currently, she explained, when an application changes the selected region (expanding it or shrinking it), ATK only informs the screen reader that the selection has changed, not what letters or words were added or de-selected. Similarly, document editors do not send formatting information (such as the "bold" or "italicized" state of text) to accessibility applications, which makes editing difficult. In both cases, she said, the application already has the information in question, it just needs a mechanism to send it via ATK. Finally, table cells have their own set of problems, starting with the fact that a cell cannot report its row-and-column position via ATK. Diggs is quick to point out that these issues do not constitute design flaws in ATK, but areas for improvement that have come out of several years of real-world use.
The list of topics for the hackfest also includes completing ATK's GObject introspection work, reviewing ATK usage in newer toolkits such as GNOME Shell's "ST" toolkit, and examining bindings for languages that do not use GType, such as C++ and Java.
During the FoG accessibility campaign, all one-time donations will be earmarked by the GNOME Foundation specifically for accessibility work, as will the first month of all new subscription plans. Sandler said that the campaign would not last for the full 2012 calendar year, although it does not currently have an end date announced. "We wanted to get it going now, though," she added, "so that folks can donate and see their tax deductions this year, if that applies to them."
The hackfest is open to any interested attendees; developers who plan on
participating can add their names to the event's planning
page on the GNOME wiki to indicate their intent. Although a schedule
for the rest of the year has not been established, there is certainly no
shortage of work needing
attention. Accessibility improvements ultimately benefit all
users; as Alan Coopersmith pointed
out on the GNOME Marketing list, former "accessibility only" projects
like speech recognition and on-screen keyboard technology are now
indispensable parts of the mobile computing experience. But, even though
everyone's eyesight will decline over the years with age, making software
accessible today will obviously have a greater — more immediate — impact for those users who happen to have visual, auditory, or motor-control impairments.
to post comments)