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

[Steve Lee <steve fullmeasure co uk>]

Willie

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.

How is AEGIS places to direct some resource to GNOME a11y, bearing in
mind this is some hardcore work?

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,
>>