Re: [orca-list] Possibly Forking Gnome 2

[Piñeiro <apinheiro igalia com>]

On 09/06/2011 09:01 PM, Thomas Ward wrote:
> Jason wrote:
>
> There needs to be a group of people who are familiar with the ATK/AT-SPI
> technology, and whose job it is to work with various projects (desktop
> environments and applications) to maintain and improve their accessibility
> support, and to improve the release processes to avoid regressions.

There are already people doing that work, and we meet each week in order
to check for the status of those projects:
https://live.gnome.org/Accessibility/Minutes


> Agreed. Not much use in upgrading if the desktops and apps begin
> breaking accessibility as we've seen recently with Gnome 3 vs Gnome
> 2.32. Someone has to watch dog the accessibility while the desktop or
> app is in development/testing else the end result will be a stable
> release with infurior accessibility. Something like this issue with
> the now infamous f2 problem in Gnome 3 could have been caught and
> fixed long ago if it had been in the hands of some accessibility watch
> dogs prior to the Gnome 3 official release.

And all those people was trying to get the accessibility status of GNOME
3.0 to be the best as possible:

https://live.gnome.org/Accessibility/ThreePointZero

And said so, we, the people that are usually on those meetings, we are
aware that GNOME 3.0 accessibility status was bad. But the main reason
is that there is a lot of work to do, there isn't too many people, and
most of the people are volunteers. I'm sorry if the status is not really
good, but this is what we have with the current workforce.

> My own interest is in other approaches to accessibility that don't involve
> significant modifications to the source code of applications. For example,
> Emacspeak works by using the extension language of Emacs (in which much of
> Emacs itself is written) to provide a spoken interface; ChromeVox takes a
> similar approach, with only minor modifications to the browser that can be
> subjected to automated testing.

So do you really think that people already creating an accessibility
support for toolkits and apps are really interesting in creating tons of
source lines of code?

> Um...Sometimes that works sometimes not. I think a wholistic
> accessibility approach is doing what we are doing with Gnome and what
> Apple is doing with their own accessibility efforts with Cocoa. If we
> build accessibility into GTK+, QT, and document how GAIL, ATK, and

Accessibility support on Apple for sure is one of the models to look at.
But comparing it with GNOME/GTK is unfair. Apple, a company gaining
millions, is paying their developers to write Cocoa and their
accessibility support. Which million-gaining company is paying to
develop GTK and their accessibility support?

> At-Spi can be integrated into a desktop application accessibility can
> be pretty much assured from the outset. Its simply a matter of making
> accessibility a core part of the development framework for desktop
> applications and write it into the standard API documentation for
> mainstream and accessibility devs alike. In other words to me
> accessibility isn't something that can simply be bolted on, but should
> be at the core of every API and toolkit from the beginning.

You can find ATK and at-spi2 code here:
http://git.gnome.org/browse/atk/
http://git.gnome.org/browse/at-spi2-core
http://git.gnome.org/browse/at-spi2-atk


You can find ATK documentation here:

http://developer.gnome.org/platform-overview/stable/atk

IMHO it is already on the core of the GNOME development framework.

Best regards

-- 
Alejandro Piñeiro Iglesias