ATRC ARIA efforts in 2008

With funding from the Mozilla Foundation and IBM, in 2008 the ATRC continued to help communities add support for accessible DHTML using ARIA. This meant a whole whack of little things, including frequent emails and chats, and some other things, like code commits, testing infrastructure work, document editing, and committee work.

My primary role was to help make sure Web2.0 communities knew about ARIA, and to help them with any implementation work through what amounted to a mutual-mentorship. I'll discuss deliverables related to this evangelism-ish goal first, and then move on to some more specific community work. Then come back at the end with some brief thoughts on the evangelism aspect.

Initially and iteratively I worked with Aaron Leventhal on strategic ways to spread awareness of ARIA. At some point we realized developers needed a place to go for sample code, and hey, code talks, baby.

codetalks.org

We started to see additional people and communities providing great resources about ARIA. As specification and best practices work continued in the W3C, we realized it would be nice to provide a central hub for all the ARIA activity and evangelism that was happening "in the wild". Together this community created a 'vendor neutral' wiki: wiki.codetalks.org, as well as an svn code repository, and bug database. These sites are hosted by the ATRC, and we plan to continue hosting them as long as they are useful. Aaron created a free-aria google group for, not surprisingly, the free discussion of ARIA. Oh, by the way, any readers good with logo design?

W3C PFWG ARIA team

Given my prior work on Dojo Toolkit Accessibility, and my colleague Joseph Scheuhammer's work on the Fluid Project, we were invited to join the ARIA specification efforts as 'invited experts'. Our input to the discussions came primarily from actually trying things out, and our work on Dojo and jQuery.

DHTML Style Guide

The ATRC continues to attend and contribute to the DHTML Style Guide meetings which address keyboard bindings for DHTML widgets.

jQuery UI

A core contributor is leading the ARIA effort here, and I feel it is in good hands, with a decent community effort; so in a sense, "job done!" The community has not finished of course, but we've got a pretty clear roadmap ahead, and we've made some good progress. As a major redesign (in UI) moves forward so does the opportunity for further ARIA support. We've added the core ARIA support and it takes about a day or two to add ARIA support, with automated tests, to a jQuery UI 'plugin' (think 'widget' or 'component'). Adding polished keyboard interaction can take longer. The ATRC's Fluid Project team, having already worked through a lot of keyboard and navigation issues on top of jQuery, is now moving this know-how upstream and working with the jQuery UI community.

Dojo (Dijit)

We continued to work with the Dojo community on dijit, the mature and accessible widget set, with a focus toward helping sustainability. Joseph was our main resource for this work and initially focussed on grid widget keyboard accessibility (non-trivial) and spent a fair amount of time doing QA, including manual tests. Later he created automated UI tests using a robot currently found in Dojo's test harness: D.O.H. and has worked to move ARIA smarts into Dojo core.

ARIA Evangelism

One thing I've struggled with in the evangelism part of our grant is knowing when we are successful, or even when we are finished. Other browsers and toolkits are adding ARIA support, but how much did the ATRC help make that happen? Did we use the right amount of pressure? Did we help enough? I think we'll never know.

One thing I do know is that the Mozilla Foundation likes to seed activities that fit its wonderful manifesto/mission. I can say that in this respect the Foundation has been very successful here, and that the ATRC continues to pursue and win funding that will allow us to continue to focus efforts on open web accessibility now and into the future.

Finally, all this experience is helping me in my current gecko work!

dojo svn notes

Late last week the dojo committer svn URL moved and it was fairly straightforward to update my Eclipse settings. I had a clean sandbox so I just blew it away, then went to the SVN Repository perspective, added "https://svn.dojotoolkit.org/view/committer" as a repos, browsed to all/trunk and checked out as a project named dojo-trunk.

I learned there is an svn switch command for changing the prefix for all the URLs in a sandbox instance which would have been good if I had uncommitted local changes.

Aside: I use my macports svn client from a shell for creating patches as it strips the irrelevant directory prefixes.

Debugging JavaScript evals

Note to self... when debugging dojo in firefox... always check the script option: "Show eval() sources" in firebug.

You might need to check this after updating minefield and/or firebug.

Thanks for the reminder today Becky.

ARIA News: Marco's Tips, jQuery, dojo

Marco has begun his promised blog series on ARIA tips! Marco, a bright new Mozilla employee is someone to listen to; he's close to the metal with respect to making accessibility work and is respected in the accessibility community.

If you are a DHTML developer you must subscribe to Marco's blog; or perish.

Oh by the way it is about time I did some other name drops. Colin Clark and I are going to be talking to John Resig and Paul Bakaus on Monday to see how we can help their community make jQuery UI rock even more with ARIA and other goodies.

We (at the ATRC) continue to help the dijit community add polish to the dojo toolkit's solid ARIA and keyboard implementation.

ARIA support is growing.

Where is David?

I've had enough requests to prompt this somewhat rare personal post. My second child, another healthy girl, Riley, was born January 6th of this month!

I feel so lucky, thrilled, and tired.

I've saved up some holiday time and will continue to focus on my family until the second half of February. High priority community work that I'm involved with will continue to get enough attention that I'm not a bottleneck, but pretty much everything else is on the backburner. Thanks for your patience.

And thanks for reading.

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.

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]

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.

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.

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.

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.

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.