Re: [orca-list] Possibly Forking Gnome 2

[hackingKK <hackingkk gmail com>]

On 07/09/11 00:31, 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.
>
> 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.

If accessibbility is at the core heart of the API for behind a certain 
desktop it aught to be also well documented.

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

+1
And since this has not happened, we see the case with firefox as of 
version 5 or 6.
They might fix the problem for now.
Or may be a certain bill coks might hack around a bit.
But unless we have some thing at the core level in the development 
framework itself as suggested, we might not have a long lasting 
accessibility with certainty that if not any thing else, it will at 
least not degrade.

Happy hacking.
Krishnakant.