GNOME.org
 

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

Hi Steve:


Thanks for a great summary of the state of play. So it seams as usual
the key issue for a11y is resource, whether to do the work or liase
with other teams.
Resources are definitely an issue. I think we will always be resource starved until we can make accessible design part of the mainstream developer's every day practice -- to use a tired management cliche, mainstream developers need to be part of the solution rather than part of the problem.
One way around this is to keep hammering away at educating mainstream developers and exposing them to a11y. This is why I typically prefer giving a11y talks at mainstream venues versus a11y venues. We had a great breakthrough with HFOSS (http://hfoss.org/) this year where we were able to capture the minds of some students who want to continue working in this space. 


How is AEGIS places to direct some resource to GNOME a11y, bearing in
mind this is some hardcore work?
AEGIS funding in various forms (e.g., EU AEGIS and Canadian AEGIS) are providing funding for the AT-SPI/D-Bus, GNOME Shell magnification, and Caribou work (Ben Konrath's more focused replacement for GOK).
Canonical is funding Luke Yelavich part time to work on SpeechDispatcher, and I'll help out with that as much as time allows. We created a small GOPA-sized grant for Joanie Diggs to work on WebKit a11y, but most of her work is really being done out of a strong passion for the space. Joanie is truly amazing.
The danger of funding dollars, however, is that they run out. Like a coin-operated ride in front of the grocery store, they are awesome while they last, but they come to end almost before you expect it. With mainstream developers making a11y design choices over their entire development cycle, I think we can reach a more cost effective and self-perpetuating culture.
On a positive note, I believe the two main spots where we are seeing responsible accessible design emerging in the mainstream are GNOME and Mozilla. We're not to the point where I'd declare victory, but I am seeing a cultural shift emerging and it is promising. 

Will



Steve Lee

2009/11/4 Willie Walker <William Walker sun com>:

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,
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]