because it is a mistake to think you can solve any major problems just with potatoes

For years I had been threatening to nuke Orca’s support for Firefox (it’s the only way to be sure) and start over. This release cycle I finally made good on my threat. 🙂

The funny thing is that what prompted me to do so was not Firefox; it was the need to implement an Orca-controlled caret for WebKitGtk content. Why an Orca-controlled caret for WebKitGtk content is needed — and why the resulting support is not yet being used for WebKitGtk content — is a rant topic for another day. But with that work largely done, and Orca’s support for Firefox in desperate need of a rewrite, the time was right.

The improvements include:

Addition of speech support for MathML. (Nemeth is a high-priority for me, but just getting something working had to happen first.)

Significant performance improvements: The lags Orca’s Firefox support had become (in)famous for should be gone — at least the ones caused by Orca, which was quite a few. I have also added some defensive handling for the accessible-event floods Orca is sometimes on the receiving end of (e.g. due to unusually large numbers of DOM changes).

Support for Google Docs applications: Just enable Google Docs’ accessibility support and Orca’s sticky focus mode, and you should be good to go.

Improved support for other rich text editors like Etherpad.

Fixes for Orca getting stuck in or skipping over content in browse mode.

Fixes for Orca getting tripped up by auto-reloading/refreshing content.

Fixes for several bugs in presentation of elements in object mode. (By the way, yes, Orca can present one object per line “like JAWS does.”)

Improved accuracy in Orca’s label inference support (because there are still authors who fail to use label elements and/or ARIA to make their form fields accessible).

Fixes for several bugs related to using structural navigation, fast forward, and rewind in SayAll. (Note: These “experimental” SayAll features still need to be enabled via your Orca customizations because GNOME’s GUI and string freezes snuck up on me. But once you’ve enabled them, they should work more reliably than before.)

Improved presentation of dynamically-added content, such as items added to the bottom of a search results page in real time.

The Saturday immediately following this year’s Grace Hopper Conference, was the second annual Grace Hopper Open Source Day, the goal of which was to get women involved in Open Source through projects with “humanitarian” aspects. The GNOME Foundation generously sponsored my travel making it possible for me to co-lead a full day on GNOME Accessibility with Western New England University’s Dr. Heidi Ellis. While I didn’t get a head count, I am guessing we had around 15 participants in our group all eager to dive in and triage a bunch of bugs filed against Orca.

Bug Triaging??

Yeah, I know, bug triaging doesn’t sound especially motivating or captivating, let alone something one would “dive in” and do. But this work was and is desperately needed: Unlike many other software tools, in which the bugs are typically in the tool itself and require no specialized knowledge to triage, what gets filed as an Orca bug might indeed be an Orca bug; then again, there’s a healthy chance it isn’t. For any given application being accessed by an Orca user, a bug hindering that access may be in:

the application itself

the toolkit(s) used by that application

the accessibility implementation of the toolkit

the bridge between that implementation and AT-SPI2

AT-SPI2

pyatspi

Orca

speech-dispatcher or the speech synthesizer

brltty, brlapi, or liblouis

Add in to the mix the fact that distros ship different versions and combinations of all of the above, sometimes even patching items to better suit their needs, and what seems like the simple task of “triage this Orca bug” can rapidly become complicated and murky. Consequently it is an area where I regularly lose quite a bit of time — time which could instead be spent actually developing Orca if only I had some bug triagers familiar with screen readers, and Orca, and Accerciser, and pyatspi, and AT-SPI2, and ….

So when the opportunity to run a project at Open Source Day presented itself, it was hard to pass up: Not only could we tackle some work that badly needed to be done, but I could train people who would then be capable of continuing to do this type of work after the event.

The Day

After the Day’s opening plenary, during which time our group’s participants quickly installed Virtual Box and imported the Fedora 18 Alpha VMs provided, I gave the participants an extreme crash course in GNOME Accessibility 101. Then it was time to GetStuffDone™. I was too busy to look at clocks, but I think everyone was working for around five hours. Many even ate lunch while working. It was like having clones — only legal and without any associated ethical concerns. 🙂 It was awesome. Towards the end of the day, I took an informal poll to see how many of the participants would be interested in forming an “Accessibility Division” of the GNOME Bugsquad. Five or six indicated they would participate in such an effort. Yay!! 🙂

Lastly, our facilitator Aravind Narayanan deserves some serious props, not to mention my extreme gratitude. Showing up and hitting the ground running on any accessibility-related task typically requires previous experience. So when I found out that our facilitator is an engineer on the Infrastructure team at Facebook working on backend distributed systems, my assumption was that he’d be smart but not able to serve as a co-lead for this project. I was wrong. Very, very wrong. Aravind was AWESOME, helping participants just as effectively as Heidi and I and contributing significantly to the project’s success. Next year if I am invited to Grace Hopper Open Source Day, I want Aravind on our team. The rest of the projects will simply have to find someone else. 😉 Thank you Aravind!!

You can’t always get what you want…

To be honest, I’m not entirely sure what I expected to get out of this hackfest. Sure, it would be a great opportunity to work face-to-face with other accessibility developers and spread the word about GNOME to the attendees of the conference. But I’d be lying were I to deny hope that Will Walker would show up, much like Bobby from the 80’s television show Dallas, to inform us that recent events had all just been a bad dream. Or, failing that, that one of the companies which ships the GNOME desktop would see the hackfest as the opportune time to announce the creation (restoration) of a full-time engineering position whose primary focus would be Orca development. Or, also failing that, I would not have objected to a visit from the Good Fairy.

Mind you, I’m not greedy. At this point I have no expectations of having (what I feel to be) an appropriate number of engineers devoted to GNOME accessibility development. All I wanted was something, anything, which would put things back to where they were before so that I could happily continue in my role of humble Orca worker bee. Alas, no such luck. As a result, I am now officially the Orca project lead/maintainer.

What exactly will happen with respect to the broader GNOME accessibility picture remains to be seen. Will went over the large list of issues facing us for GNOME 3.0. A few items (CSPI and GOK, for instance) got slated for deprecation, and many of us at the hackfest volunteered to take on what remained. But I was really hoping we’d also walk away from the hackfest with a new leader: someone who could see both the forest and its trees, serve as the GNOME community’s “point person” for accessibility issues, and herd us cats accessibility developers into a cohesive, focused group. In other words, another Will Walker. But that hope was dashed along with my other hopes when no one stepped up to try to fill Will’s shoes. I still truly believe that we’ll find our way, and that in the end it’ll all be good; at the moment, however, I’m just not sure how that will come to pass.

…But if you try sometimes, you just might find you get what you need.

As I keep reminding myself, I must focus on what I can do; not on what I cannot. What I can do is continue to work on Orca, and things are starting to look up on that front:

Growing the team

While Oracle has yet to officially acknowledge my Open Letter, it seems they are doing the more important thing, namely starting to respond to the concerns raised therein: They sent Li Yuan and Ke Wang, two engineers from Oracle/Sun Beijing, to the hackfest. Will led a session in which the four of us went over Orca’s internals with the aim of getting Li and Ke sufficiently up to speed to contribute to Orca. It is my understanding that Li will be able to add a bit of time for Orca to the accessibility work he is already doing, and that Ke will be able to spend 50% of his time working on accessibility, including Orca. Phew! Thanks guys for joining the team. And thank you Oracle for continuing to support this project.

Alejandro Piñeiro of Igalia also attended the hackfest. Alejandro has been working on Cally (accessibility support for Clutter) and is now taking a look at getting Orca working with gnome-shell. Thank goodness! An inaccessible gnome-shell would be a major setback for GNOME accessibility, but I had no idea how I was supposed to fit that issue on my own to-do list. It was great to have the opportunity to continue the discussions about Orca he and I had at the Boston Summit last October. And while it, too, remains to be seen, I’m hopeful that Alejandro (and/or another developer from Igalia) will be able to join the Orca team to address some of the other issues we’re facing. Regardless, thank you Alejandro for all your work. And thanks to Igalia for its ongoing support of GNOME accessibility.

Testing

Going from being a one-(wo)man team to being a member of a potentially four-person team is itself a great outcome for this hackfest, but I also had the good fortune to spend some quality time with Mozilla’s accessibility guys, Marco Zehe, David Bolter, and Alexander Surkov. We talked quite a bit about testing and now have a plan for both sides to better detect and prevent regressions. This should go a long way in ensuring that GNOME users who are blind continue to have compelling access to Firefox.

I also had a chance to talk with Mike Gorse and clarify some aspects of the Orca regression test suite so that he can use our tests as a means to ensure that the work he is doing with AT-SPI over DBus behaves as expected.

That the ÆGIS Project is going to be working with the community to start tackling the broader issue of accessibility testing in GNOME was yet another piece of welcome news. After all, time that does not need to be spent on hunting down accessibility regressions in other applications is time that can be spent on making Orca even better.

Going forward

Will and I went over what I need to do to make a release. (You’re right, it is a piece of cake. But thanks for going over it with me! One less thing for me to stress over…. 🙂 )

Last, but not least, I am extremely touched by the 2009 Louis Braille Bicentennial Silver Dollar which was presented to me by Peter Korn and the rest of the GNOME a11y guys for my work on Orca. It was neither expected nor necessary, but with everything going on these days it was very (very, very) much appreciated and lifted my spirits considerably regarding the future. You guys are the best!!

So all in all I’d say it was well worth getting over my dislike of travel (not to mention my complete and utter fear of flying) to attend this event. 🙂 Many, many thanks to Eitan for taking on the mammoth task of organizing all of it — and us! And thanks again to the GNOME Foundation for making it possible for me to attend.

You don’t know me, so please permit me a brief introduction: I’m Joanie. By day, I’m an assistive technology specialist working with individuals who are blind or visually impaired. By night, weekend, and holiday for almost four years now, I’ve been a GNOME community contributor working primarily on the Orca screen reader, a project led by Sun’s Accessibility Program Office.

Working with the engineers at Sun, both inside and outside of the APO, has been an honor for a variety of reasons, not least of which is our shared common belief: Access isn’t a privilege; it’s a right. Towards that end, Sun Microsystems strived to ensure that ALL users have access to software and information.

Does Oracle plan to do the same?

Sun Microsystems believed that these things shouldn’t be denied to those who aren’t employed, or who don’t live in the “right” country, or who don’t speak the “right” language, or who cannot afford to purchase thousands of dollars’ worth of access technology.

What does Oracle believe?

Through its significant, ongoing contributions to the GNOME desktop, Sun Microsystems has made computer access possible for many individuals with disabilities, from all walks of life, all over the world.

Will Oracle embrace the opportunity to continue this important work?

My assumption was yes. In fact, I was feeling quite hopeful. After all, the past few years have been hard on Sun. But with Larry Ellison’s promise of increased investment in the Sun brand, and Oracle’s strong commitment to accessibility, things would finally be turning around: If one under-funded APO could accomplish everything that it has, what could the two combined and properly-funded APOs achieve? At the very least we’d be able to finally get a handle on all of the accessibility challenges facing GNOME 3.

I was wrong. 🙁

Last week, Oracle laid off two more members of Sun’s already-decimated APO. One of those let go happened to be both the Orca project lead and the GNOME Accessibility project lead, Willie Walker. I truly hope this was an oversight on Oracle’s part, and one that will be rectified very soon. Because if it is not, and if no other company steps forward to continue this work, the accessibility of the GNOME desktop will become the open source equivalent of an unfunded mandate, doomed ultimately to fail.

Oracle’s decision threatens to leave many individuals with disabilities around the world without access to a modern desktop environment. I find that tragic.

BOSTON, Mass – February 27, 2008 – The GNOME Foundation is running an
accessibility outreach program, offering USD$50,000 to be split among
individuals. This program will promote software accessibility awareness
among the GNOME community as well as harden and improve the overall
quality of the GNOME accessibility offering.

The program is sponsored by GNOME Foundation, Mozilla Foundation,
Google™’s Open Source Program Office, Canonical, and Novell. This is the
second in a series of outreach programs coordinated and run by the GNOME
Foundation.

“I’m excited about the GNOME accessibility outreach program because it
continues the promotion of compelling accessible design as part of the
mainstream developer culture. We believe the set of tangible and
achievable tasks outlined will help improve the already good
accessibility offering of the GNOME desktop,” said Willie Walker, Senior
Staff Engineer of Sun Microsystems, Inc.

GNOME Outreach Program: Accessibility starts accepting applications on
March 1st and will run towards the end of the year. There will be two
tracks to the program: In the first track accepted individuals will work
towards accomplishing one of the major projects nominated for the
program, earning US$6,000 and can take up to six months to complete the
task. The second track will reward contributors US$1,000 for fixing five
bugs out of a pool of accessibility bugs nominated by the program
judges.