Last week, thanks to a generous travel sponsorship from the GNOME Foundation, I attended the 25th annual CSUN Conference -- or more accurately, I attended the 1st (annual?) GNOME Accessibility Hackfest which took place at the conference.

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.

Now for the hard part: Getting everything we've set out to do done....

A year ago, almost to the day, several users of Orca screen reader had expressed an interest in using Claws Mail instead of Evolution (currently the default mail client of the GNOME desktop) or Thunderbird. The Orca team is very small, but we do our best to implement the features and support requested by our users -- in addition to working on those critical features that any screen reader should have and fixing the bugs which, alas, exist. So I took a look at Claws Mail from an accessibility point of view. After all, if Claws Mail uses standard Gtk, it shouldn't be too hard to implement support in Orca.

The good news: Claws mail is (as I recall) mostly standard Gtk. Yea!

The bad news: There are a few custom widgets which are not accessible, and there is no caret navigation implemented when reading messages. These two issues prevent us from being able to implement support. Had I more time in the day, I might be able to at least generate a proof-of-concept patch for the first issue, but my current skill level is not likely such that I could implement caret navigation. So, as is custom in the open source world, I opened a couple of bugs:

• Accessibility events missing in FolderView and SummaryView
• Add support for caret navigation/selection

And, as is sadly too often custom in the accessibility world, they languished. Until today:

It looks like nobody has been interested in implementing this feature since the end of 2007; in order to clean up the bugzilla, I'm marking this WONTFIX.

Features in Claws Mail get implemented on a developer-interest basis: if one of the core developers codes a feature, or if an external contributor provides a good patch, the feature gets added. If the feature interests nobody with coding abilities, although it seems nicer to leave old requests lingering in Bugzilla and let the submitter hope the feature will be added someday, it's more honest (and cleaner) to close them as WONTFIX.

Fail.

I suppose I should at least give the Claws Mail guys credit for being honest and stating that they're not interested in accessibility, but it is a shame for the end user.

Now back to focusing on implementing support in Orca where it belongs: on those applications whose developers ARE interested....

Will thinks that if we write the developers of websites whose content is inaccessible (or a challenge to access), those developers will fix their problems. I used to believe that as well. It may take a village to raise a child, but unfortunately it seems to take lawsuit in federal court to raise awareness. But seeing as how Will is Orca project lead whereas I am a humble community contributor, and seeing as how I have taken to mumbling the words "crappy markup" in Will's general direction as I continue my work on Orca's support for Firefox, I suppose the very least I can do is give his idea a shot.

Today's note went to Safeway.com via their online suggestion form:

Dear Safeway.com:

I'd like to bring to your attention the W3C's Web Accessibility Initiative. There you will find a number of resources which you can take advantage of when evaluating your site's content for accessibility. In particular, please see Guideline 1 of the Web Content Accessibility Guidelines: Provide equivalent alternatives to auditory and visual content.

1.1 Provide a text equivalent for every non-text element (e.g., via "alt", "longdesc", or in element content). This includes: images, graphical representations of text (including symbols), image map regions, animations (e.g., animated GIFs), applets and programmatic objects, ascii art, frames, scripts, images used as list bullets, spacers, graphical buttons, sounds (played with or without user interaction), stand-alone audio files, audio tracks of video, and video. [Priority 1]

For example, in HTML:

• Use "alt" for the IMG, INPUT, and APPLET elements, or provide a text equivalent in the content of the OBJECT and APPLET elements.
• For complex content (e.g., a chart) where the "alt" text does not provide a complete text equivalent, provide an additional description using, for example, "longdesc" with IMG or FRAME, a link inside an OBJECT element, or a description link.
• For image maps, either use the "alt" attribute with AREA, or use the MAP element with A elements (and other text) as content.

At the bottom of your site you have an imagemap:

<map name="links">
<area alt="" coords="0,0,48,28" href="javascript:loadframesetpages('','http://www.vons.com','0','','')">
<area alt="" coords="48,30,124,0" href="javascript:loadframesetpages('','http://www.dominicks.com','0','','')">
<area alt="" coords="193,0,124,33" href="javascript:loadframesetpages('','http://www.randalls.com','0','','')">
[...]
</map>

Because your alternative text is an empty string, the items within your imagemap are inaccessible to users who are blind. Providing the name of the store (alt="Vons") should resolve this problem.

Thank you in advance for your attention to this matter!

Here's to hoping...

Will just announced the release of Orca 2.21.4.

I just need to repeat how amazed I am at how much work we got done this release. The last release was only 2 weeks ago, yet we accomplished a lot in the areas of performance, bugs, magnification, and Firefox. It's difficult for me to choose any one of these as being the highlight of this release [...]

Agreed on all counts! The Orca team is awesome. And we really did accomplish a huge amount in the past couple of weeks, all of which is detailed in Will's announcement.

I'm not normally one to toot my own horn, preferring instead to be just "another member of the team." Besides, I don't own a horn.... But I feel the need to toot... something... just this once because... well... I worked awfully darn hard the past couple of weeks. When I wasn't doing my "day job" or sleeping, I was working on the magnification features for this release. Given that several times I woke up with an idea or a solution for implementing a feature, I apparently was even working while sleeping. And I am still cleaning crumbs out of my keyboard. Phew!

I'm also not normally one to toot the horn of others, but I'm going to make an exception there as well because the herculean effort that went into the new magnification features was only half my doing. It was a tag-team effort with the other half being done by Rich who, I might add, has the patience and tolerance of a saint ("Rich, I know it's Sunday evening, but I'm adding new features and I need....").

I thought tag-teaming might be challenging with really large patches going back and forth, and trying to keep all of the changes straight, but it all happened quite smoothly -- aside from one minor mishap where I inadvertently converted an enormous Glade file from the version the team is using (2) to a version it's not (3). Oops.... And then checked it in. D'oh!

Anyhoo, with no further ado, Orca's new magnification features:

• Support "live updating" when setting various magnification features

  Changes made to the zoomer in the Orca Preferences now update in real time: it is no longer necessary to press the Apply button to see if the option you've chosen works for you and then undo it or adjust it if it doesn't. Note that you must still press the Apply or the OK button to make your changes permanent.

• Bug #452316 - should have a "fullscreen" checkbox

  We've added a Position combo box so that it's easy to select the position of the zoomer. The options are full screen, left half, right half, top half, bottom half, and custom. Choosing custom allows you to specify the location of each edge of the zoomer. The new default zoomer position is full screen if full screen magnification is possible. Otherwise, the right half of the screen will be used by default.

• Bug #463881 - Evaluate other gnome-mag features for inclusion in Orca prefs

  You can now adjust the brightness and contrast levels and use the colorblind filters from libcolorblind. Basic brightness and contrast levels can be adjusted through the spin buttons on the Magnifier pane of the Orca Preferences dialog. If you press the Advanced Settings button at the bottom of that pane, you'll be placed in a dialog box where you can customize the red, green, and blue brightness levels and contrast levels individually. The Advanced Settings dialog is also where you can choose a color filter. These options should enable you to create the color scheme that works best for you.

  You can also add a border to your zoomer to help separate it from the non-magnified area. The border size and color are customizable. We've also separated the cursor color from the cross-hair color so you no longer have to find the one color that works best for both.

• Bug #464705 - Provide option to keep caret in center of magnifier region of interest

  We've added individual tracking and alignment settings for controls and the text cursor: each can have an alignment of centered or push (move the magnifier window the least). In addition, you can now specify an edge margin for the text cursor. This margin is how close the caret should be allowed to get to the edge of the screen before it's time to "push." The margin can range from 0 to 50%, with 50% being the equivalent of choosing centering. These options should make it easier to keep track of your location on the screen and ensure that you can always see the area around your point of focus.

• Bug #501414 - Orca should have (unbound) keybindings for quickly changing magnification settings

  We've added the following new commands:

  • Toggle color enhancements
  • Toggle mouse enhancements
  • Increase magnification level
  • Decrease magnification level
  • Cycle to the next magnifier position
  • Toggle magnifier on/off

  These should help you quickly change the zoomer to best access what you're working on. These commands are "unbound," meaning they do not have a keystroke assigned to them. You can define the keystrokes you would like to use on the Key Bindings pane of the Orca Preferences dialog: locate each command you wish to define a keystroke for, move to the Key Binding column, and press Return. You'll be prompted for the new key. Press it (rather than type it out) and then press Return. Note that these commands do not permanently change the settings; they merely alter them "on the fly."

• Bug #503965 - Orca should provide support for the pointer following focus and the zoomer

  If you're using the keyboard to perform a task and then move the mouse pointer, the zoomer would move away from your task and to the location of the mouse pointer. We've added two options for dealing with this:

  • Pointer follows zoomer (enabled by default): If the mouse pointer is not on the screen when you initially move the mouse, it will be moved into the zoomer so that you can continue to see what you were working on. If your preferred mouse tracking mode is centered, the pointer will be moved to the center; otherwise it will be moved to the item with focus.
  • Pointer follows focus (disabled by default): If this option is enabled, the mouse pointer will follow you as you arrow through menu items and move among controls in dialog boxes.

We've still got a ways to go with our magnification support: bugs to fix, performance to improve, more gnome-mag features to implement, and support for Compiz eZoom. Still, what we accomplished in this release is huge I think. Thanks Rich!!

Break out the champagne 'cause the label guess functionality for Orca has just been checked in!

In case you're wondering -- and even if you're not, which I realize is far more likely to be the case -- guessing form field labels is something that screen readers such as Orca need to do because most web designers do not follow the W3C Recommendations for labeling form fields. Were these designers to do so, filling out forms on the web would be really accessible to people who are blind: The user would simply press Tab/Shift Tab to move from field to field and the screen reader would in turn announce the label for that field thus informing the user about the information he/she was expected to enter. But web designers don't do this. As a result, as the user moves from field to field all he/she knows is that something needs to be typed here. Who knows what that something is? So the user has to leave the field and arrow around in the hopes of being able to figure out what text applies to that particular field and, having done so, work his/her way back to that field to actually provide that information. One field down, a bunch more to go.... To put it bluntly, it sucks to fill out forms on the web if you happen to be blind -- unless your screen reader is able to accurately guess the text that is functioning as the label.

Orca now guesses labels -- and if I do say so myself, does a nice job of it. Now it's just a matter of refining the heuristics as feedback from users comes in.

It was not a trivial task, programmatically doing the work sighted users do automatically. In fact, the resulting patch wound up being about 10% of Gecko.py! Granted some of that is related cleanup and modifications, but the bulk of it is the addition of code to look spatially at the form field and try to determine based on the type of field, the location of surrounding text, and the presence/absence of other objects of various and sundry types, exactly what is serving as the label. Fortunately, as is often the case in the open source world, someone stepped forward with a suggested approach which I was able to use as my basis for implementation. Thanks Tom!

Onward and upward....

One of the many nice things about developing a free, open source screen reader like Orca is that you're not tied to a "bottom line" which dictates your priorities and design decisions. So if your number one goal in life is NOT getting your users to part company with the contents of their wallet, what on earth do you focus on??? Hmmm..... I dunno.... maybe.... the users and what they want and need? (Now there's a novel idea, eh?)

In this regard, the Orca team has been actively working with the community from the get-go, communicating primarily through the Orca mailing list. But our little community has grown and become quite lively over recent months, so Mike Pedersen (UI lead) had a brilliant idea: Start having live, user-developer "round tables" where we can share ideas in real time. The first such meeting will be tomorrow at 5PM EDT (21:00 UTC) in #orca at irc.gnome.org. The plan is to rotate the times. After all, given that we have users all over the world, whatever time we pick is going to be 4 AM for somebody. Because Luke Yelavich (aka TheMuso) archives all of the #orca channel logs, there will be a transcript available for anyone who cannot attend.