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

[Vincent Untz]

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

--
Les gens heureux ne sont pas pressés.
_______________________________________________
gnome-accessibility-list mailing list
gnome-accessibility-list@...
http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list

[Ben Konrath-3]

Hi Vincent,

I can't speak for other accessibility projects but I can give you a
summary from the On-screen Keyboard point of view. The On-screen
Keyboard effort currently consists of two projects: GOK [1] and Caribou [2].

For GOK, we are working on removing dependencies on deprecated libraries
for the March 2010 release of GNOME. We are not, however, planning to
move GOK over to the new DBus based atspi so GOK will only work if
distros decide to ship the CORBA based atspi - I believe Will Walker is
working on allowing both versions to be installed at the same time. I
will let Will talk about this in more detail.

Caribou is currently being developed as an alternative to GOK for GNOME
3. We are targeting the September 2010 release of GNOME for our first
release.

Cheers, Ben

[1] http://www.gok.ca
[2] http://live.gnome.org/Caribou

On 11/03/2009 11:14 AM, 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
>

_______________________________________________
gnome-accessibility-list mailing list
gnome-accessibility-list@...
http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list

[Willie Walker]

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
>

_______________________________________________
gnome-accessibility-list mailing list
gnome-accessibility-list@...
http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list

[Steve Lee-3]

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@...>:

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

_______________________________________________
gnome-accessibility-list mailing list
gnome-accessibility-list@...
http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list

[Willie Walker]

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@...>:
>> 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,
>>>

_______________________________________________
gnome-accessibility-list mailing list
gnome-accessibility-list@...
http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list

[Steve Lee-3]

2009/11/5 Willie Walker <William.Walker@...>:
> 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.

That was great. Lets see if there is a way of getting
project:possibility students involved. To date they have worked on new
projects, which is good for their motivation but bad for the projects
which are then left languishing. It would be good to explore ways for
some them do GNOME features that are needed and can be done within
either the SS12 weekend or the longer Semesta. They would need
mentoring as they are CS students on course that have no OSS or a11y
components and doing it extra curricular. To date it has also been a
feature of P:P to get mentors who are fairly new in industry.


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

This is excellent to hear. Also good the hear there is now a name - Caribou

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

+1 - beyond 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.

Absolutely, and even more so when part of a diverse community around
each project and also GNOME a11y. The question is how to nurture it?

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

I agree with that, and have seen it grow in strength from the first
time Aaron invited me to the GNOME/Mozilla summits a couple of years
back. Even from my rather distant position.

Steve
_______________________________________________
gnome-accessibility-list mailing list
gnome-accessibility-list@...
http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list

[Willie Walker]

Hi Steve:

(release team removed from TO/CC)

> That was great. Lets see if there is a way of getting
> project:possibility students involved. To date they have worked on new
> projects, which is good for their motivation but bad for the projects
> which are then left languishing. It would be good to explore ways for
> some them do GNOME features that are needed and can be done within
> either the SS12 weekend or the longer Semesta. They would need
> mentoring as they are CS students on course that have no OSS or a11y
> components and doing it extra curricular. To date it has also been a
> feature of P:P to get mentors who are fairly new in industry.

I think there's a few sides to this.

One of the most important sides is getting accessible design
considerations to be made by application and toolkit developers
themselves.  This is the thing that needs a cultural shift like the one
we are seeing in GNOME and Mozilla.  Things that can help with this are
presentations, "quick read" documents that introduce people to the space
without overwhelming them, exposure to people with disabilities, etc.
The hard part for technology people coming into the a11y space is that
this side is more about education and documentation than writing code or
twisting knobs on a CNC machine.

Another side is developing the access solutions themselves.  IMO, these
need to be done in cooperation with end users and domain experts with a
focus on providing solutions for end users vs. just developing
technology for the sake of developing technology.  Operating in an
insular manner (e.g., closing your eyes and pretending you are blind and
then coming up with a solution that you tell blind people they need)
doesn't always yield good results.  From the Project:Possibility web
site, it appears as though it may be tied in well with the accessibility
community, so that's good.

Another side is development tools that encourage accessible design
(e.g., "sorry, you cannot save your work on this GUI layout because it
is inaccessible." ;-)).  These tools also include testing/emulation
facilities, such as something that will change the colors of the entire
display so it emulates various levels/types of color blindness.

>> 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.
>
> Absolutely, and even more so when part of a diverse community around
> each project and also GNOME a11y. The question is how to nurture it?


Education, advocacy, and sex appeal. :-)

Will
_______________________________________________
gnome-accessibility-list mailing list
gnome-accessibility-list@...
http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list

[Francesco Fumanti]

Hi,

Willie Walker wrote:

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

These two paragraphs make me wonder the following:

- Is there any contact between the GNOME A11y Team and the GNOME Shell
developers?

- Do the GNOME Shell developers know what properties have to be present
in the GNOME Shell to make it support a11y? As apparently, the GNOME
Shell is still a moving target, the sooner the GNOME Shell developers
know what to take care of, the better it will be for everybody; not only
for the disabled people requiring assistive tools, but probably also for
the GNOME Shell itself to have the best chances to become a widely used
desktop. (Is a11y not a requirement under specific circumstances to be
even accepted as a candidate for a computer system!?)

Consequently, if it makes sense, maybe somebody with the required
knowledge should contact the GNOME Shell developers to talk directly
with them about the a11y in the GNOME Shell and if appropriate, inform
them about the properties they should take into account during the
development, or the rest of the development. And by these properties I
don't mean general guidelines, but very concrete points like complete
keyboard navigation, complete pointer navigation, specific
interfaces,... (Please, be aware that I don't really know what the
necessary properties are; the three points that I gave in the preceding
sentence are only guesses.)


Cheers

Francesco
_______________________________________________
gnome-accessibility-list mailing list
gnome-accessibility-list@...
http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list

[Willie Walker]

Hi Francesco:

> - Is there any contact between the GNOME A11y Team and the GNOME Shell
> developers?

Yes.

> - Do the GNOME Shell developers know what properties have to be present
> in the GNOME Shell to make it support a11y? As apparently, the GNOME
> Shell is still a moving target, the sooner the GNOME Shell developers
> know what to take care of, the better it will be for everybody; not only
> for the disabled people requiring assistive tools, but probably also for
> the GNOME Shell itself to have the best chances to become a widely used
> desktop. (Is a11y not a requirement under specific circumstances to be
> even accepted as a candidate for a computer system!?)

We've pointed out that keyboard traversal, communication with the
AT-SPI, and theming are important.  These are core fundamental things
that the current solution does not provide.

Note that the GNOME Shell team is churning away and developing rapidly.
We need them to succeed and provide something sexy for GNOME 3.0.  The
churn, IMO, is the result of them needing to experiment with various
solutions.  One important thing is the decision about which graphical
toolkit they end up using -- right now, they are using their own fork of
NBTK.  This toolkit, which is inaccessible, is likely the thing that
will end up needing the work.  Note, however, that it doesn't make sense
to invest heavily in making it accessible if they are going to drop it
for something else.

As I mention, I can resign myself to the fact that the message about
a11y has been delivered and received.  The GNOME Shell team, which is
composed of senior members of the GNOME community, has information
needed to help them include a11y in their decision making.  For now, I'm
OK with keeping out of their way, but will keep advocating they include
a11y in their decision making processes.

So, on one side, I'm advocating strongly for a11y, and on another I am
sensitive to the issues the GNOME Shell team is facing at the moment.

Will
_______________________________________________
gnome-accessibility-list mailing list
gnome-accessibility-list@...
http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list

[Piñeiro]

From: Francesco Fumanti <francesco.fumanti@...>

> These two paragraphs make me wonder the following:
>
> - Is there any contact between the GNOME A11y Team and the GNOME Shell
> developers?
>
> - Do the GNOME Shell developers know what properties have to be present
> in the GNOME Shell to make it support a11y? As apparently, the GNOME
> Shell is still a moving target, the sooner the GNOME Shell developers
> know what to take care of, the better it will be for everybody; not only
> for the disabled people requiring assistive tools, but probably also for
> the GNOME Shell itself to have the best chances to become a widely used
> desktop. (Is a11y not a requirement under specific circumstances to be
> even accepted as a candidate for a computer system!?)

Take a look to this two mails in the gnome-shell mailing list:

* http://mail.gnome.org/archives/gnome-shell-list/2009-November/msg00009.html

  A general description from Owen Taylor (one of the main gnome-shell
  developers) about gnome-shell current status , with a paragraph
  related to the accessibility.

* http://mail.gnome.org/archives/gnome-shell-list/2009-November/msg00018.html

  A answer to the previous mail, explaining the current plans for the
  development of Cally (Clutter accessibility library).

> Consequently, if it makes sense, maybe somebody with the required
> knowledge should contact the GNOME Shell developers to talk directly
> with them about the a11y in the GNOME Shell and if appropriate, inform
> them about the properties they should take into account during the
> development, or the rest of the development. And by these properties I
> don't mean general guidelines, but very concrete points like complete
> keyboard navigation, complete pointer navigation, specific
> interfaces,... (Please, be aware that I don't really know what the
> necessary properties are; the three points that I gave in the preceding
> sentence are only guesses.)

Work in process (AFAIK) ...

===
API (apinheiro@...)
_______________________________________________
gnome-accessibility-list mailing list
gnome-accessibility-list@...
http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list

[Steve Lee-3]

2009/11/5 Willie Walker <William.Walker@...>:
> I think there's a few sides to this.

And another is to expose CS students to the concepts so they take them
forwards with them into industry experience.

Steve
_______________________________________________
gnome-accessibility-list mailing list
gnome-accessibility-list@...
http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list