Tag Archives: Accessibility

Funding Gnome a11y

As many of you may have heard, from blogs by Eitan, Mike and Joanie, as well as an e-mail to the gnome-foundation-lists by Fernando, the Gnome a11y community is having a tough time.

I have been interacting with the a11y community for over two years now, and in that time the funding situation has never looked good. I do not wish to insult or demean companies that are no-longer involved in funding Gnome a11y. Companies and individuals have their own priorities that they must follow. Work they have done in the past on Gnome is very much appreciated by me, even if they cannot continue that work in-to the future.

That said, I believe that in the past two and a half years Gnome a11y has lost a huge amount of funding. First from IBM, which, to many peoples dismay, pulled out of a11y funding before I started work on AT-SPI. I was glad to hear that Mozilla is providing $10,000 to the Gnome foundation for a11y work. I’m extremely grateful for that, but I do not believe that Mozilla are providing the level of funding that they have done in the past. Our work on AT-SPI D-Bus has been funded jointly by Codethink, Sun, and another un-named benefactor. None of this funding is likely to continue past the end of February. All of this would seem slight were it not for the news that Oracle have let-go of important Gnome a11y community members working for the Sun Accessibility Project Office. Sun have been the major contributor to Gnome a11y, and this is a worrying signal that Oracle do not intend to continue the current level of contribution.

Assuming that Oracle do not wish to involve themselves in Gnome a11y, my back-of-the-envelope calculations indicate that we may have lost greater than $200,000 in anual funding over the last three years.

Although huge amounts of Gnome development takes place un-funded, by hackers, volunteers, users and hobbyists you would probably be surprised how much is done by folks working a 9-5. I don’t expect the figures to be the same, but as an example, 75% of kernel developers are paid by corporations for their work. The loss of the Sun Accessibility Project Office and other sources of funding will be felt very heavily by the Gnome a11y community.

Accessibility is incredibly important to the Gnome project, and not only to its users. Gnome has a fantastic, credible, accessibility story. This, to me, marks Gnome out as a class ‘A’ open-source project. Were we to lose this, it would be a turning point. In my eyes Gnome would then be a project in decline.

What can we do?

Firstly we need to go on a cohesive search for funding. The Linux Foundation has an accessibility group that I have been involved in for a long time. This seems to me the best place to combine our efforts in the great funding drive. Funding channeled through the Linux Foundation would not be Gnome specific, but cross desktop a11y technology is what we have long been striving for.

Ideally enough funding would be found to hire someone to work full time on Linux Desktop accessibility.

Outside of the search for cash all Gnome developers need to spend more time on accessibility. Its not always easy to make ones application accessible, and I’m sure it can seem daunting. There are still a11y community members ready to help out though. All is not lost. :) I’m damn near certain that we are going to pull together. Gnome 3.0 will have the same great accessibility that has made me proud of past Gnome releases.

Gnome, KDE & Mono A11y

Congrats Mono A11y

Many congratulations to Mono Accessibility, team for getting their first release out into the open.  The Mono A11y team must be one of the largest open-source A11y groups out there and I’m really excited about the work they are doing. WinForms and Moonlight are not yet my thing, but if Silverlight takes off the UIA provider they have created will undoubtedly form an essential part of Linux accessibility.

I don’t believe that it will be in the first release, but I’m really keen to see work start on the UIA client library for Mono. C# and Mono sound like a great place for developing new ATs.

AT-SPI D-Bus on freedesktop.org

For people who don’t know about Gnome accessibility or AT-SPI D-Bus:

AT-SPI D-Bus is a project which aims to use D-Bus instead of ORBit/CORBA as the IPC mechanism for Linux accessibility. For anyone interested in finding out about the Gnome accessibility architecture the developers page has some good information. Oddly enough KDE has a very good Gnome A11y overview, and Sun has a good diagram. Long story short the AT-SPI D-Bus aims to write a new, D-Bus based adapter for ATK, a registry daemon, and client libraries that are API compatible with the existing cspi and pyatspi.

The project has a new home on the freedesktop.org servers.

The code-base exists at:  git://anongit.freedesktop.org/git/at-spi2/at-spi2-core.git.

We are keeping a page on the linux-foundation wiki updated with all our progress. Unfortunately I’d say that the code is not yet ready for a first release. For reasons soon evident the code isn’t currently getting the love it deserves. (Help MUCH appreciated)

The reason we chose freedesktop.org and the Linux Foundation instead of Gnome hosting is that we wanted to emphasize the cross-desktop possibilities of a D-Bus based accessibility architecture.

Gnome, KDE & Mono: How it all fits together

The Mono A11y architecture diagram is missing something important that the AT-SPI D-Bus project can add – QT accessibility.

The drive to D-Bus accessibility came from ORBit deprecation, the embedded community and an ideal of cross-desktop accessibility. Its the last motive that has me most excited right now. QT currently has a D-Bus framework based heavily off AT-SPI, but unfortunately it has never been taken far enough to be compatible with existing AT-SPI ATs. The reason that the ATK, cspi and pyatspi libraries are not getting my attention right now is that I really want to get started on bringing QT into the mix.

A QT adapter for AT-SPI D-Bus will certainly round-out the Accessibility infrastructure on Linux. Not being involved in the KDE community I don’t have much say on how they do A11y, but I hope to make it as easy as possible for them to choose AT-SPI D-Bus. Along with the Mono work this could mean that QT, GTK, ATK, Winforms & Swing apps are accessible, using the same ATs, in both KDE and Gnome. I think that would be a fantastic achievement. If we work hard enough accessibility could be one of the big success stories of a joint Akademy/Guadec next year.

D-Bus Accessibility – Its alive(ish)

This may not look like much more than another screen-shot of Accerciser. You’ll have to trust me that is Accerciser inspecting firefox-2 over D-Bus. Its the first visible step in a long project aiming to replace ORBit with D-Bus for the AT-SPI accessibility protocol.

accerciserliverpool

Mike Gorse and I have been hacking on this for a little over four months now, and its been pretty slow going. I’m very happy to finally have something to show for it.

So much to do…

What we have however isn’t quite the finished article. One of the main goals of the project is to help bring together Gnome and KDE accessibility. I believe that QT already has an ATK implementation, but I think it would make more sense for the QT accessibility interfaces to meet directly with the AT-SPI D-Bus protocol, a project that has not-yet begun.

On the ATK-Bridge / Pyatspi side there is still a huge amount of testing and bug fixing to do, along with a fair few missing features.

So much to test…

Its testing thats really occupying my thoughts at the moment. A while back, on a linux-foundation conference call, I remeber a conversation about how to test the pyatspi and cspi interfaces.

The conclusions were:

  • Have lots of small applications, each exposing only a few accessible objects and concentrating on a single accessible interface, such as the Component or Image interface.
  • Have a unit test written for cspi or pyatspi that is partnered with one of the mini applications, and inspects it over the AT-SPI protocol.

I have made a poor attempt to unit test pyatspi in this way, but I found it was a-lot of work to get any coverage. I think this is down to my choice of implementing a dummy ATK framework to create the applications. Mini GTK applications would have done just as well.

The advantage of lots of these mini applications and unit tests is that when someone comes to implement the AT-SPI protocol with a new widget set, or with new client side bindings they have something simple to validate against.

Where to go

The repository for the D-Bus AT-SPI work is still on the Codethink servers. It won’t be there for long though, there are plans for the project to be hosted at freedesktop.org soon.

D-Bus AT-SPI is well underway

Work is starting on the port of the AT-SPI framework to D-Bus. Codethink are, graciously, being funded by Nokia to undertake the work. Mike Gorse is working on the project full time, as part of his work for Novell.

Mike has got alot done and there are some initial D-Bus specifications, as well as alot of code on the ATK to AT-SPI adapter side. For the moment we’ll both be working in a git repository on Codethink. Hopefully we will be able to move the code into a repository on freedesktop one day.

The AT-SPI D-Bus work is important as it is attempting to eliminate the last vestiges of CORBA from Gnome and at the same time help with cross desktop accessibility. I’m hopeful that despite the transition we will be able to create a flexible and performant D-Bus protocol for AT-SPI.

I’ve written before about our results on D-Bus vs CORBA performance, done in preparation for this project. The results were a bit shocking for the D-Bus team so there need to be some significant changes to the IPC for things to remain snappy.

A week of head scratching and ranting

I’ve taken part in a couple of phone calls this week, a quick conversation with Michael Meeks and a conference call with the open a11y group. Both about AT-SPI D-bus. There was a week of silence after my initial e-mail to lots of accessibility lists, and after that something of a storm. It was good to actually hear everyones opinion, I think people care, and AT-SPI D-Bus will probably happen sooner rather than later.

Thats pretty good news as Rob and I have spent LOTS of time discussing this one, with some of it being rather heated. Its all about “standardising” the AT-SPI interface, what constitutes a “component” system, and whether accessibility really needs object lifecycle management. :) Could anyone really have raised voices in a conversation about that?

I’m going to put together our thoughts / proposals for everyone to go through. (With heavy input / modification from Rob Taylor) Hopefully it will be up to scratch.

Unexpected results

I really enjoy profiling and optimization, mainly for those WTF moments when results pop out the other end. Systems rarely behave the way anyone expects, and I doubt anyone would have expected this:

Wierd D-Bus performance

The graph is showing time taken to pass many many messages of different size fixed arrays over D-Bus and ORBit. At about 120k message size, Libdbus hits a performance brick wall. Its really hard for me to imagine whats going on here, but as soon as I have the time I’ll go back and do my best to find out.

D-Bus performance and AT-SPI

As part of work we (Codethink) are doing for the Mozilla foundation I have been looking, at the performance of D-Bus vs ORBit. Its a well traveled road with Ross Burton, Havoc Pennington and Frank Dunigan all having posted results before. As far as AT-SPI is concerned though its Frank’s results that are quoted on the Open A11y wiki. “An alpha version of the D-Bus bindings for glib has been tested to be 18x slower than ORBit2″. Well this is no longer true, the tests were repeated and the results show a big improvement over time. D-Bus is now roughly 6 times slower. Its a wonder these haven’t been repeated before over the years. I guess the main thing is performance of the IPC for most apps just isn’t important. It might be for AT-SPI though, from the initial tests done on Orca, its a pretty heavy user.

All of the results can be found at:
http://live.gnome.org/GAP/AtSpiDbusInvestigation.