Red Hat and GNOME Accessibility?

Oddly, it is a message from Matthew Szulik as he leaves the role of CEO and President of Red Hat that renews my hope that Red Hat takes accessibility seriously. Why?

In reading that it is important at Red Hat to "seek out those who believe that for any democracy to continue, free and unfettered access to information is an unassailable condition for advancement", I'm struck by the term "unfettered", where I take the term to mean accessible and without barriers.

Please tell me that's what he mean't. Please tell me the new CEO and President, Jim Whitehurst will make that a company directive. I think with that directive in hand, Jonathan Blandford and the desktop team could really make a brilliant impact in GNOME accessibility. With the community looking at an accessibility infrastructure refactor, the timing is right.

Sun Microsystems, having laid the GNOME accessibility foundation, are still chugging away with the classy ORCA screen reader, and helping support GOK maintenance; as well as strategic thinking.

IBM, no longer directly involved in Linux accessibility are still involved peripherally, and are tackling accessibility on many fronts.

Ubuntu has seemed to "get it" from day one. Bravo!

The Mozilla Foundation continues to provide vital seed funding for GNOME accessibility work, bringing in great talent to work on gaps.

Novell seems to understand the importance of this and are putting resources behind it.

I'm sure I'm missing some obvious ones; please leave a comment and let me know.

Exciting times! Thanks for reading.

[Edited to fix name of company! Thanks David Z.]

Invigorating GNOME Accessibility

Teaser: something really cool is coming next year.

A few days ago Behdad gathered some of us GNOME accessibility folks together on IRC to brainstorm which he then summarized and reported back to the board.

Today Brian Cameron posted to the GNOME accessibility list with the subject: "Forming an Accessibility Steering Committee". If you are passionate about accessibility and feel you have the experience and time why don't throw your name in the hat? I imagine one of the things that the committee will help steer is (I'm whispering now...) the cool thing coming next year, but that is only a piece of puzzle.

I don't know what has gotten into Behdad lately but he is definitely helping bring people together around accessibility.

Great job!

Be careful with "this"!

If you've ever struggled with registering JavaScript object methods as callbacks, you're bound to enjoy this recent post by ATRC colleague Simon Bates:

Registering JavaScript object methods as callbacks

I hope it brings you closure.

Transparency in Community Decisions

Transparency should be applied to how decisions can get made in FOSS communities. This can involve different layers; for example, transparency could apply to:

1. Who gets to participate in decision making.
2. How these people are selected.
3. The process of decision making.

In FOSS communities I think transparency should apply to all three where reasonably possible. What do I mean by this? Let's take a couple of examples:

A) Getting hired by a FOSS organization which is integral to the community.
B) Getting commit access to an svn repository.
C) Getting syndication of one's blog onto a planet/aggregator.

A FOSS community might decide on the following transparency for each example:

For A: Transparency of 2 only.
For B: Transparency of 1, 2 and optionally a moderated version of 3.
For C: Transparency of 1, 2, and 3.

How might the transparency by realized?

Let's take example C, the blog syndication; the decision maker(s) should be known, perhaps listed right on the planet. The way the decision makers were chosen should be known, this could exist on a wiki page, perhaps in the governance section of the project wiki site. The decision process could be made transparent by requiring a public trac ticket for every blog that gets added, with the required number of decision makers commenting on the ticket directly, for all to see. As an added bonus, the community could chime in on the ticket with opinions.

Transparency can help avoid conspiracy theories.

Graceful Degradation is Good

Hmmm, what do you do when you impulsively blog something and then change your mind?

My last post, titled "Progressive Enhancement++", looked at how one of the principles of progressive enhancement calls for unobtrusive JavaScript, which calls for graceful degradation. I said I was not fond of this latter principle. That's silly of course! Silly, silly, silly. At least for now.

Progressive Enhancement++

First off, I don't mean to imply Wikipedia is fact.

According to Wikipedia, "Progressive Enhancement consists of the following core principles:
* basic content should be accessible to all browsers
* basic functionality should be accessible to all browsers
* sparse, semantic markup contains all content
* enhanced layout is provided by externally linked CSS
* enhanced behavior is provided by unobtrusive, externally linked JavaScript
* end user browser preferences are respected"

I'll ignore the problems defining what constitutes "content" in the world of DHTML applications, but notice above the reference to unobtrusive JavaScript. According to Wikipedia, one of the basic principles of unobtrusive JavaScript is "Graceful degradation in browsers that are unable to express the behavior layer in the desired manner"

I'm not terribly fond of this latter principle. A bit strange for an accessibility guy eh? Well. JavaScript is a great language, is becoming available in all sorts of places (including browsers on mobile devices), and can now be made accessible using ARIA. In fact, when DHTML is designed well, and using an ARIA enabled browser like Firefox, the experience for users of assistive technology can be greatly improved.

I don't think there is a term for what I see as an alternate design strategy: one that looks a lot like progressive enhancement, but does not strive to work in a JavaScript-less environment.

Mobile Research

I've been meaning to report about my growing involvement in the mobile space.

I'm involved in a mobile device research entity here at the ATRC called SCYP and we just launched our call for proposals. We want to change the world on a shoe string and we need help. Of course I'm steering the project towards free and open technologies... and attending the weekly standups with a swanky new N810 maemo* in hand just might help that along. Oh that, and I'm providing technical oversight for this research entity, which affords me some influence.

Any folks who want to get involved and have a project in mind, or are already doing stuff you think we should know about feel free to comment below or email scyp at atrc dot utoronto dot ca.

*Note: On November 12th I learned I was one of 500 lucky people to be accepted into the N810 maemo device program. Thanks!

Directed Giving at Mozilla

Aaron Leventhal just dropped a note on the dev-accessibility mozilla list that the Mozilla directing giving program is now live!

See Frank Hecker's blog: directed-giving.

In his note Aaron provides a direct link to the Mozilla accessibility donation page:
http://www.mozilla.org/access/donate.html

Accessible CAPTCHA

Every voice is important, except for spammers.

CAPTCHA stands for "Completely Automated Public Turing test to tell Computers and Humans Apart". Here's one that claims to be accessible:reCAPTCHA.

It will be great to see those communities that understand the future is for everyone start using accessible CAPTCHAs. It is also just good business sense.

Dojo 1.0!

Dojo the javascript toolkit version 1.0 is ready for download.

Dojo has three main bits: dojo, the tight handy core, dijit, the accessible widgets, and dojox, the dojo/dijit breeding ground.

Thanks to IBM and Mozilla and others for helping make dijit accessible!

FSOSS 2007 (part 2)

Wow. The Free Software & Open Source Symposium (FSOSS) sure attracts some interesting people.

I enjoyed all the talks I attended but I want to specifically mention David Eaves' presentation titled "Community Management as Open Source's Core Competency" where he took a critical look at communication and negotiation in open source communities. It was just great. I also enjoyed the colourful session which followed, by Jesse Hirsh, "The Problem with Open Source: Know Your History". During both of these talks I found it refreshing to stand back and take a critical look at the open source communities. I am sorry to have missed the related BOF, but I had a lunch date with Frank Hecker from the Mozilla Foundation to discuss accessibility and to blue sky for a bit; which I thoroughly enjoyed.

Anyways I feel honoured to have been invited by David Humphrey to give a talk on Accessible DHTML, which I had more teasingly titled "Accessible Rich Internet Applications". Simon Bates and I co-presented on Friday and discussed and demonstrated keyboard control, ARIA semantics, and other bits related to our Dojo toolkit work. I think Simon's iterative coding demo showed that adding keyboard and semantics to DHTML is not that difficult, but is undeniably important; which was our main goal.

For those interested, Simon has provided the slides and source code on his site.

Building Firefox with Accessibility on OS X

I wanted to check out Minefield on Mac OS X so I went about doing what I do in my Ubuntu virtual machine. I ran into a few snags that were a result of my own silliness. Once I created a clean profile and ran Firefox the right way on Mac it was all good. Here's a rough log of what I did:

cvs -d :pserver:anonymous@cvs-mirror.mozilla.org:/cvsroot co mozilla/client.mk
cd mozilla
make -f client.mk checkout MOZ_CO_PROJECT=browser
cvs -d :pserver:anonymous@cvs-mirror.mozilla.org:/cvsroot co mozilla/browser/config/mozconfig

I created a .mozconfig file with debug options:

. $topsrcdir/browser/config/mozconfig
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/ff-debug
mk_add_options MOZ_CO_PROJECT=browser
ac_add_options --disable-optimize
ac_add_options --enable-debug
ac_add_options --enable-accessibility

Then I installed some mac ports as suggested by the Mozilla docs.

sudo port selfupdate
sudo port install libidl
* this installed glib-2.14.1 for me
sudo port install autoconf213
make -f client.mk build MOZ_CURRENT_PROJECT=browser

Running ff-debug/dist/bin/firefox crashed so I got onto #developers and Colin Barrett (cbarrett) helped me out. I asked him if my FF2 addons could be interfereing and he suggested I create a clean profile. I forgot about this, arrg. After creating a clean profile ff-debug/dist/bin/firefox ran!
Still no apple menu though a bit more chatting and Colin mentioned I need to run the the Mac way: dist/MinefieldDebug.app/Contents/MacOS/firefox

Woohoo! VoiceOver is sorta working too, I just have to figure out why it reports Firefox is busy sometimes when it doesn't appear busy. I think Håkan Waara warned me about this.

Mozilla and GNOME Summits

I wasn't able to attend this year's Boston summits for Mozilla Accessibility and GNOME. If you know me, you know this was painful to miss and I'm sorry I was not able to blog about it for others who couldn't make it this year. Fortunately Steve Lee has blogged about it on a sleepy train ride back home.

Debugging Dojo

I'm a firebug fan so I use fireclipse. It is basically firebug with support for debugging into eval() expressions. It is quite impressive considering SpiderMonkey is not designed to support easy debugging of eval(). If you are curious about the bug I recommend reading John Barten's great description of the problem. I'm not sure when that might get resolved.

In the meantime, I'm grateful for fireclipse.

FSOSS 2007

The Sixth Annual Free Software and Open Source Symposium will be held on October 25th and 26th in Toronto Canada again and registration is open. That's only about five weeks away! I really have to send Dave Humphrey my talk title soon... as soon as I decide exactly what I'm going to talk about. Well we know it will be related to accessibility.

Dojo: DOM events and consistent UX?

I recently posted on this topic to the public dojo/dijit forums but am now casting it to the blogosphere in hope of synergistic bliss (AKA "readers correcting my misunderstandings").

User interaction with a dijit is enabled by our listening for events such as:
1. click
2. mousedown
3. mouseup
4. keypress (fixed/normalized in dojo/_base/event.js)
5. etc.

The interesting thing about click is that it is abstract and device agnostic. For example an html checkbox onclick will be called under the following conditions:

On Firefox, space key up, and left mouse button up.
On Webkit, space key down, left mouse button up.
On IE7, space key up, left mouse buttion up.

In an onclick handler we don't know and presumably are not supposed to care what caused the event.

Right now, in dijit, we have a mixture of device agnostic handling (via onclick), and device speciifc handling (via onmouse__ and onkey__). This means we can't reasonably provide UI/Ux consistency of control.

Note to self: one thing I need to check out is the status of (on)click support for all elements via keyboard and mouse.

In other words, sometimes a user might activate something by pressing space, and another time, on another dijit, by releasing space. This can lead to dangerous things like stray events activating unsuspecting buttons (see related dojo ticket:3281, and firefox bug:384601).

What can we do about this?

Simon and I have discussed this a bit yesterday and have some ideas, such as rewriting/normalizing click if necessar, and perhaps enabling it for nodes the browser implementation might not.

[I've edited this post slightly since the original]

Ken Saunders - Mozilla Volunteer

Ken is the project manager for the Access Firefox website. This site is an incredible resource for people from the accessibility and disability communities. It provides information on the accessibility features of Firefox, and suggests optional extensions that provide even more options over the way you can interact with the web. In his words:

"The information here will point you to the tools that will help you to get the most of using the Internet. Because of Firefox and its accessibility features, the time that I spend surfing the Internet is more fun and productive again."

Like many of us who are drawn to Mozilla, he believes in a free and open internet.

Oh by the way, Ken is also a graphic artist and happens to be legally blind. I like his icons; here's an example:

Call to Arms: Free and Accessible Desktop

Our free and accessible desktop needs help.

It appears IBM will no longer have employees working on native Linux accessibility. I really don't know if this says anything about how Linux fits into IBM's corporate strategy, or if it is more about of the huge importance and focus on Internet accessibility (above the desktop). It might just be a case of too "many irons in the fire". I am pleased to hear IBM will continue to do important work in open source and accessibility.

Still... sadness.

I hope Sun can continue the great work they do in this area but it is a heavy torch to carry. There is a lot of work and I'd like to see more from the distros and other companies that understand that the future is open and that it is for everyone.

See Peter Parente's email to some linux accessibility lists. Peter intends to continue his important contributions off-the-clock. I hope he can. Note he lists a number of projects that may be affected: Accerciser, pyatspi, LSR (at least the current GNOME incantation), Linux Accessibility on the Firefox and the Mozilla platform, AT-SPI Collections.

See also, Rich Schwertfeger's blog post.

Dojo Developer Day (3DNY)

First, let me just say "use dojo 0.9 or greater!" It is API incompatible with 0.4.X but it is the future of dojo. It is leaner, quicker, and... well... better.

OK, I know this blog is a bit shoddy and doesn't flow... but our schedule is really tight and I shouldn't be spending much time blogging.

Simon and I flew into New York Friday morning, sped over to the Manhattan IBM building in a cab, and after setting off alarms, getting our badges, and waiting around, Alex Russell showed up and let us in. We were just in time for introductions where I learned about people's giant pet cats, failed music bands, and other secrets. It was basically a big getting-to-know-each-other, followed by break out sessions. After lunch we really started to make some progress getting a picture of dijit status and planning for 0.9 beta.

The evening started at ESPN Zone, a sports bar in Madison Square, and then a handful of us proceeded to the Belmont, a lounge in Union Square. I am a beer guy, but still I highly recommend the passion fruit mohito.

Saturday was much the same but included more people using (not just contributing to) dojo toolkit.

See also Alex Russell's blog: 3DNY Wrapup

...and Flickr pics from Alex and others.

FLUID

Today I attended, in an advisory capacity, a day long meeting to launch the Fluid project. The core architecture is being designed here at the ATRC, which is located at the University of Toronto; but there are many partners including other Universities as well as industrial partners and other projects. What is Fluid? The website has this text:

"The FLUID project will create a user interface architecture that enables the creation and consistent use of modular, reusable, and swappable user interface components. The project will develop a living library of robust, usable, accessible UI components, which can be reused across applications, contributed to, and evolved by the community."

I think the components will be DHTML based. Fluid will investigate and hopefully be able to choose an exisiting Javascript GUI toolkit to build on.

There were about 17 of us at the face-to-face meeting and it went very well. Most time was spent on the topic of governance which is so important to get right early (see a related blog:Handling Disagreements in Open Collaborative Projects by Frank Hecker)

It was a great first meeting.

IMG onload reassignment

Hacking on a dojo dijit widget today I came across some strange behaviour that only seemed to happen in IE. Turns out the reassignment of an image node's onload was causing the new onload hander to fire. Here's the code that reassigns onload:

img.onload = function(){ self.onImageLoad(); }

IE is not open source so I can't diagnose exactly why the onload fires when reassigned. I worked around it by making sure that the premature firing would not be harmful.

Aaron Anderson and XUL Accessibility

Aaron co-founded www.xulplanet.com.

He joined WebAIM about two years ago, and last Fall began a xul accessibility project funded by the Mozilla Foundation. His project has recently concluded, and produced the XUL Accessibility Guidelines and a XUL Accessibility Tool. The guidelines help XUL developers write accessible code, and the tool provides a report on the accessibility of XUL files.

Aaron also keeps a blog.

planet.gnome.org

I'm here! Thanks jdub.

HTML inputs, MVC, changing the view

I did some exploration recently into how one might take advantage of built in (browser) form input widget "model" and "control", while providing a different "view".

Some approaches:
1. transparent overlay test, are mouse and keyboard events captured by the invisible overlay? ...not in IE.
2. off screen test, html radio buttons are to the left and above the browser client area (works but might have accessibility issues).

Note code quality is exploratory.

Charles L. Chen

Charles L. Chen is in the US working on the Fire Vox and CLiCk, Speak extensions for Firefox.

Fire Vox is a screen reading extension for Firefox. It has features not commonly found in commercial screen readers, such as built-in support for MathML, CSS 3 speech properties, and WAI-ARIA Live Regions.

Unlike Fire Vox which is designed for visually impaired users, CLiCk, Speak is designed for sighted users who want text-to-speech functionality. It has a simple, mouse driven interface that is designed to be easy for users familiar with point-and-click graphical user interfaces.

Charles recently created test cases of accessible AJAX live regions by using the WAI-ARIA live region markup. This work was funded by the Mozilla Foundation.

In his spare time, Charles likes to help out Knowbility.

Gijs Kruitbosch and ChatZilla

Gijs is a 19-year-old student from the University of Amsterdam, where he's halfway through a B.Sc. in Artificial Intelligence. He has been involved in the Mozilla community since his first patch in November 2004. Within Mozilla, Gijs mostly works on ChatZilla (the Mozilla IRC client). Last summer, he participated as a student in Google's Summer of Code and recently he started working on a project funded by the Mozilla Foundation to make ChatZilla accessible.

He drank a lot of Sprite at CSUN this year.

Steve Lee and Jambu

Steve Lee is in the UK working on Jambu, a software project funded by the Mozilla Foundation. The goal is to provide first class support for users of alternative input devices such as switches. The tool will use XULRunner, a runtime for supporting XUL applications on the same platforms you find Firefox and Thunderbird. Steve, actively promotes open standards and open source with an emphasis on accessibility, assistive technology and education.

Steve also keeps a blog and hacks on music.

The 'onchange' event

My recent dojo work has led me to exploring JavaScript event reassignment and specifically to the intricacies of the onchange event of html input elements.

The HTML 4.01 Specification says this about the onchange event:

"The onchange event occurs when a control loses the input focus and its value has been modified since gaining focus. This attribute applies to the following elements: INPUT, SELECT, and TEXTAREA."

Okay. Well currently Firefox doesn't follow this (at least for radio buttons), but instead does something outrageous; it fires an onchange event if something changes, for example, if the radio button checked state changes. (Although I hear it "correctly" fires onchange for a text input only when it loses focus; perhaps to avoid the event noise that would occur during text entry).

Sarcasm aside, I imagine there are good reasons for the HTML Specification but I can't help but think, at least in the post submit-page-refresh model of web development, that we could stand to have a more immediate onchange event, perhaps called onvaluechange?

Some hacky vanilla test code is in my exploratory. Yes, I've taken a liking to using the word exploratory as a noun.

CSUNzilla part 2: Impressions

Mozilla rocked CSUN last week.

In this post I hope to share a little of what I experienced at the conference. I will be blogging a little over the next few weeks about what people in the extended Mozilla accessibility community are doing. For now, I'll give a brief sampling of the event as it might relate to Mozilla.

The Mozilla Foundation reserved a room for meetings, group hacking, and demos. This was a brilliant success, and the fact that this room was shared with others, such as the Linux accessibility folks, gave the CSUN community a taste of what Mozilla is all about.



Tim Riley from Mozilla Corp. helped staff the booth, and in the hacking room he gave a talk about the role QA plays at MoCo. I was able to share a few meals with Tim where I learned more about the Mozilla developer culture and the way testing techniques can be integrated into that environment in a way that is both helpful to the development process, and helps build an even better product.

Creators of screen readers and other assistive technology (AT) products have been working with Mozilla to enable a better user experience. If you are interested, WebAIM has a visual simulation of a screen reader.

The Mozilla Foundation sent me and others from the ATRC to CSUN and I thank them for it deeply. Thank you Frank Hecker, the Foundation board, and Aaron Leventhal for getting people from all over the world together to talk about and work on freedom and choice in access to information whether it be Mozilla product compatibility, web semantics for DHTML accessibility (ARIA, microformats), or accessible choice on free operating systems such as Linux.

CSUNzilla

Firefox accessibility star Aaron Leventhal helps set up the booth on Wednesday:


A typical CSUN Mozilla booth moment on Thursday:

In the middle of the crowd are Charles Chen, creator of Fire Vox, and Frank Hecker from the Mozilla Foundation.

Javascript Hacking at CSUN

We hacked on dojotoolkit ARIA stuff today in the Mozilla hacking room. Shown in the pic above are Becky Gibson, Simon Bates, Gijs Kruitbosch, and Earl Johnson (photo by David Bolter).

The Mozilla booth is busy and lots of people have expressed their appreciation. So much is happening here and theres so little time to blog about it!

We're still hacking/meeting now and I hope to blog in more detail tomorrow...

CSUN Mozilla Hacking

Mozilla is kindly sending me to CSUN!

Next week is CSUN, the "Technology & Persons with Disabilities Conference" and I look forward to mingling with the amazing community that assembles there every year. When not flitting about or helping out with the Mozilla booth I'll likely be in a room Aaron has reserved for group hacking and problem solving where I will meet with talented people some of whom I know only through IRC, email, blogs, and bugzilla.

Due to scheduling conflicts I won't fly in to LA until Wednesday. I'm looking forward to the change in climate as I was out shoveling snow this morning.

In related news, I think that Deb or Robert are going to pull my feed into Planet Mozilla soon so I hope to blog a bit of the CSUN experience for the enjoyment of our extended community.

olpc

Jim Gettys from laptop.org emailed me the other day to offer me an OLPC X0-1 developer system so that I might work on getting on-screen keyboard support on Sugar.



I think it is time to start hunting for new talent to help with this work. I started an olpc thread over on the mozilla a11y development list to see if the Jambu project might be a good option here but I'm pretty sure Steve Lee has his hands full without having to target Sugar.

I think Sugar could benefit best with some customized OSK work whether use GOK, Jambu, onBoard, or something new. If you are interested in helping out contact me or Jim. Please note that "helping out" means "doing the work".

Solving Disability (continued)

Note to self:

"...for people without disabilities, technology makes things convenient, whereas for people with disabilities, it makes things possible."
Judy Heumann, 1998

Dojo Accessibility

I've been blogging recently on a shared blog called dojoa11y. Today I posted a potential implementation for radio button arrow navigation which I hacked on tonight.

My day was spent doing crazy things like trying to revive my GNOME svn account (I lost my private key) and struggling with an i915 video driver xorg config on Ubuntu Edgy. Ah well... now I'm going to put a dvd on... 'night.

Accessible Planet

I took a few moments yesterday to revive the cron job for the accessibility planet I set up a while back. I think this might be worth polishing up and might try to get some volunteer help. Right now we house the planet at aplanet.atrc.utoronto.ca. I am sure it needs some work even to make it accessible (ahem). For instance I or someone needs to have alt text support added to the blog face/logo pics.

(hil)ARIA

warning: bad poetry follows:

popups that look like tooltips,
but act like dialog boxes,
links as buttons,
buttons as menus,
manipulate the DOM,
javascript inside,
a first class browser,
power,
expose via accessibility,
venerable desktop roles and states,
web2.0,
navigate the wilderness,
challenge the rules,
break them,
wild.

Loading a XUL file in Thunderbird

Want the straight goods? Skip to the end.

I wrote a XUL test file to profile the impact of updating the accessible tree cache more frequently. The idea is to see if it is worth trying to optimize how we update the core tree accessible caches. I currently only regularly build Thunderbird trunk. So in order to run the test I needed to load the file in tbird. After poking around the GUI... no luck. I headed over to #maildev and #xul... mrfinkle and I chatted about how to solve the problem via the creation of an extension. He pointed me to a handy extension wizard, as well as information on using an extension in test mode. I'm noting this for a rainy day as I'm sure it will come in handy but I also heard from philor over on #maildev who had run into the same problem before and like me didn't want to create an extension just to test 1 file.

His solution? Set the start page in the preferences to be the XUL file. Nice.

GOK-Blocked

I've been putting some major GOK issues on hold until I can give some proper attention. I think I can start allotting 1 day a week to GOK again starting next week. The GDM login issue needs closure and I need to review some xevie work from Bill and go over the committed libusb work from Ben. I really want to test that out.

We should probably really start figuring out ways to pull some of this great work out of GOK and into separate modules.

XUL Trees, Localized Actions, TBird Tracker, and ARIA

I've closed a number of bugs since my last post but today was particularly fun.

XUL Trees

I made a breakthrough on a pesky focus bug which turned out to be a core problem. There is a clever caching mechanism in the accessibility infrastructure for storing and retrieving accessible objects (pointers really). Trees are special beasts which handle their own caches. It turns out the accessible objects stored in a tree's cache are hashed on the row and column (aRow * kMaxTreeColumns + columnIndex). Now the bug...

When a row was deleted, the remaining rows shuffled up (as rows tend to do when a row above them is deleted). So the next row in the tree (yeah I know "row in the tree" might sound funny) will now have same row index as the row which was deleted. Because the next row is focused by default it will cause a focus event to fire. The focus event fires and reports the accessible object to be the one it pulls out of the cache hashed on the row value (column won't be different). This object is erroneously the deleted row.

The fix? Well we need to update the cache when these kinds of DOM mutations occur. My current patch builds on Aaron's work to fire a new kind of dom event which results in a tree invalidation event which will cause a cache update.

What remains is to possibly optimize the cache updating strategy as well as to consider a more broad solution for other kinds of tree mutations.

Localized Actions

Accessible action names are no longer to be localized in mozilla. This came from discussion on the gnome-accessiblity-devel list on the thread "Are action names localized?". I'm currently assigned to this bug.

Tbird Tracker

I added a Thunderbird accessibility tracker bug last night. I thought I'd just note it here so that I had it handy and in case others take interest.

ARIA

Tomorrow I officially embark on another Mozilla funded project building ARIA, or "Accessible Rich Internet Applications". I will joining the dojo ARIA efforts of Becky and others.

Mozilla source code contribution!

I'm happy to report that I've being finding more time lately to work on patches to fix Thunderbird accessibility issues. In fact...

My first patch finally went into the mozilla codebase today!

First the technical bits...

The patch makes an email message's graphical status indicators accessible. These indicators include things like read/unread status which is normally a small or large green dot. To achieve this I implemented GetCellValue for the XUL tree view (part of the nsITreeView interface, implemented in a C++ class known to tbird developers as msgDBView). Implementing GetCellText to return text for these status indicators would have created conflict between the text and the graphical icon. Implementing GetCellValue provided a way for the accessibility infrastructure to query for a textual representation of the various status areas (which I added to nsXULTreeitemAccessible::GetName).

The patch touched the following modules: accessible, dom, mail, mailnews.

Now the fuzzier bits...

I can't say enough about how welcoming this community has been to me, and it has been an absolute joy working with them. I think as I began my Thunderbird work I was too hesitant to seek help from the community for fear that I would draining valuable resources, but that perspective has changed and I think I can really help out here in the long term. That will probably have to wait however as it appears I am soon going to be doing some ARIA work, in particular, dojo accessibility! I'll post something on that later.

For me, this was a really interesting first bug fix.

If Julie Andrews hacked on Mozilla...

Foxes on irc channels and newbies with questions
Bright helpful brattle and warm fuzzy kittens
XPCOM IDLs XUL PRUnichar strings
These are a few of my favorite things!
Chrome colored ponies and mozilla strudels
Bind doorbells and sleigh bells with XBL noodles
Thunderbirds fly with the moon on their wings
These are a few of my favorite things!
Hackers in dresses with blue satin sashes
Snowflakes that stay on my nose and eye lashes
Third party skinning gives firefox bling
These are a few of my favorite things!
When the bugs bite, and tinderbox stings
When I'm feeling sad,
I simply remember
my favorite things
and then I don't feeel so bad!
Foxes on irc channels and newbies with questions
Bright helpful brattle and warm fuzzy kittens
XPCOM IDLs XUL PRUnichar strings
These are a few of my favorite things!