GNOME.org
 

Re: Request for comment (accessibility team): release date for GNOME 3.0

Hi All:
In a nutshell -- IMO, GNOME 2.30 might be good enough to call a "Preview for GNOME 3.0", but nowhere near something we should call GNOME 3.0. We want GNOME 3.0 to be solid and sexy for everyone. GNOME 2.32 is probably the earliest we should shoot for. I might also suggest we create a few more point releases for GNOME 2.28 as a means to keep some stability in GNOME while the transition is being made.
For longish details, perhaps with some diatribes from a mind that is a bit concerned at the moment, read on. I did take at least 10 breaths before pressing the "Send" button, too. You don't want to see my earlier drafts. ;-)
As we discussed at GNOME Boston, we are currently facing a "perfect storm" when it comes to GNOME Accessibility. The three major fronts that are converging together are as follows: 

1) Bonobo Deprecation (AT-SPI/D-Bus, SpeechDispatcher, GNOME Shell mag)
2) WebKit a11y
3) GNOME Shell a11y
Other weather patterns, such as frequent unfortunate regressions in gdm a11y[1], are things that aren't new to us and stuff we generally just need to absorb by our very small team.
The Bonobo Deprecation work is being tracked at http://live.gnome.org/Accessibility/BonoboDeprecation. We are generally on target for getting a Bonobo/CORBA-free a11y stack (including speech and magnification) by GNOME 2.30, but I would feel uncomfortable calling it polished by GNOME 2.30. I would instead be more inclined to call it a "preview" that we can polish for Sep 2010 at the earliest.
The AT-SPI/D-Bus work is chugging along. We hope to have something in place by early next week where AT-SPI/D-Bus will be the default for GNOME 2.29 and AT-SPI/CORBA will also be available as a backup. Once we get this in people's hands for larger testing, we'll have a better idea of where we stand.
There is a concern that CSPI is not slated to be ported to D-Bus, unless resources magically appear and join our mythically large a11y army. ;-) We're working to understand the impact of this, with the biggest consumer being GOK. As Ben Konrath mentioned, he's working on a new Python/pyatspi-based utility that might supplant GOK, so it might eliminate the need for CSPI. Ben's work isn't due to land until Sep 2010, though.
The speech stack is a bit of an issue, but the good thing is that the approach (migrating to SpeechDispatcher from gnome-speech) is something that Ubuntu has been shipping for a while now. As a result, it's getting some good testing coverage from end users. It also has being met with mixed results, mostly due to PulseAudio issues as well as a nasty speech dispatcher crasher that remains elusive.
Speech dispatcher also needs to be tested (and perhaps fixed) on thin devices such as the SunRay.
There are minimal resources for the speech work and I'm concerned. Since this work might be something of interest to other groups (e.g., using GNOME on your small mobile device to do a speaking GPS), I'm hoping we can get some help somewhere.
For magnification, there are two potential solutions. The first one (porting gnome-mag to D-Bus) is being investigated by the last known gnome-mag maintainer in his spare time, but there are no commitments. The second solution is being done by Dr. Joseph Scheuhammer at the ATRC. Joseph is incorporating magnification directly into GNOME Shell. The work is progressing well, and I hope we can see some success for GNOME 2.30. The difficult part, however, is that GNOME Shell is currently inaccessible. As a result, we have a dependency relation set up on an inaccessible component. Scary.
Joanmarie Diggs has taken on the burden of digging into WebKit internals for a11y and she's doing a fantastic job at it. The opportunity cost of needing Joanie to backfill the WebKit a11y internals work, however, is that we're basically tabling all but the highest priority Orca work and work in other areas (e.g., OOo and Firefox). I'm hoping Igalia can pick back up on the WebKit a11y work[2]. My goal would be to achieve a good first milestone, which is that yelp/WebKit will be accessible. After that, WebKit then needs to start rolling in support for ARIA.
I've saved the biggest unknown for last: GNOME Shell. We had some good discussions about GNOME Shell a11y at GNOME Boston. At the surface level, I believe people agree GNOME Shell a11y is necessary. 

However...
GNOME Shell is lacking when it comes to communicating with the AT-SPI. API has looked at doing some a11y work in clutter, but this work is likely be too low in the stack. GNOME Shell has also recently introduced their NBTK fork, ST, which provides a toolkit on top of clutter. This might be a place to put ATK support, but there are no resources allocated to the task. API might take a look (which would be awesome).
With the exception of pressing the Windows key to bring up the shell view and pressing Alt+Tab to switch between windows, keyboard navigation in GNOME Shell is non-existent. You must use a pointing device to interact with GNOME Shell right now and there are no plans to add keyboard navigation to GNOME Shell.
Theming is supported in GNOME Shell's own way and is not at all integrated with the GNOME themes, so this is another issue.
GNOME Shell also makes some assumptions about the kinds of windows that appear on the desktop. This can potentially cause interaction issues with things like on screen keyboards and assistive technologies that use window for highlighting objects on the display. This needs to be investigated and resolved.
The final kicker for GNOME Shell is that it is an actively churning moving target. The ancient model that the a11y cleanup team will come in afterwards and resolve a11y issues cannot possibly work in this case. As with every project, I truly believe that accessible design needs to be part of on-going GNOME Shell development by the people developing GNOME Shell. If we can get that to happen, I'd feel much better, but I'm just not seeing that happen right now.
Right now, I think all I can resign to is that GNOME Shell will be actively churning up to and beyond the GNOME 2.30 code freeze. We'll then have to somehow try to figure out how to clean up the a11y issues for 2.32, but with no resources. Based upon past experiences with other teams, I also expect a11y fixes will likely be met with resistance from the GNOME Shell team because the fixes will do two things: 1) draw the team's attention from other work they need to do, and 2) possibly conflict with design choices that could have been done differently had they made a11y part of their earlier design discussions. Accounting for a11y sooner than later will save time and frustration in the long run.
So...GNOME 2.30? Can you spell "FAT CHANCE"? :-) GNOME 2.32? Possibly, but with the assumption that a11y remains a core value among all GNOME developers and not just the a11y team. 

Will
[1] - I *hope* we can eventually reach a situation where the gdm a11y solution is compelling. The work done by RedHat is a step in that direction. It opened some great doors, but also introduced some challenges in the process. I think the problems are solvable, though.
[2] - My understanding is that as soon as WebKit was accepted as a dependency, the WebKit a11y work was dropped because there were too many other general WebKit issues that needed resolution. 

Vincent Untz wrote:

Hi,

The release team is gathering comments from various teams to get a
proper idea of which of March or September 2010 is more appropriate for
the release of GNOME 3.0. The decision for the release date is following
what we set in the 3.0 planning document [1]: we want 3.0 to be out in
2010, but we also want to make sure that 3.0 is rock-solid; your input
will help us take an informed decision.

It'd be great if someone could summarize the status of the work that is
being done in your team (especially for the new at-spi, and also the new
on-screen keyboard and magnifier), and how March or September would work
for you. (Willie: feel free to just quickly say what you told me during
the Summit -- that was really great input)

Thanks,

Vincent

PS: make sure to cc the release team for the reply ;-)

[1] http://live.gnome.org/ThreePointZero/Plan
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]