There's something about prototypal inheritance...

Let's look at some JavaScript, and today I'll ask Crockford to pass the sugar:

Object.create = function (o) {
    function F() {}
    F.prototype = o;
    return new F();
};

Now let's create an object a, and a two objects b and c based on a.

var a = { name: "a" };
var b = Object.create(a);
var c = Object.create(a);
c.name = "c";

At this point both a and b have name "a", and c has a customized name "c". Now lets change a:

a.name = "foo";

Objects a and b now have name "foo", and c still gets to keep name "c" (a good language design decision methinks). Since a is just a mutable object we wield this sort of godly power to change or inject DNA. Every time I come back to it, it tickles me.

Using .attr for ARIA in jQuery UI

Last week I found some time to hack on jQuery UI again. After talking to Scott we decided to pull the ariaRole, and ariaState API out of UI core, and put the browser normalization for ARIA right into the popular attr function where it belongs.

At this time, jQuery UI is a dependency for this enhanced attr function. We add the ARIA smarts in ui.core.js via proxy function, like this:

// proxy attr
var attr = $.attr;
$.attr = function () {
    // if aria usage then normalize
    // else
    attr.apply(arguments);
};

See the patch for the real deal. You might notice that we actually only proxy if a naughty browser/version is sniffed. Let's hope this ARIA normalization business won't grow too big and complex when the other browser ARIA implementations roll out. If we can keep it small and tight the attr enhancement really belongs in jQuery core. Or maybe it belongs there regardless? If you are doing Web2.0 development you're probably going to need it.

Here's an example of how one might use chaining to add the ARIA role of "tab" to all elements with a class "ui-accordion-header), and the ARIA state "aria-expanded=false", and add the ARIA role "tabpanel" to the next sibling of each (which happens to be the panels).

$(".ui-accordion-header")
    .attr('role','tab')
    .attr('aria-expanded','false')
    .next()
    .attr('role','tabpanel');

Working with Scott González and others on jQuery has been a very meaningful aspect of my Mozilla Foundation grant. Thanks Mozilla.

Thanks for reading.

WAI-ARIA evangelism, dojo, jQuery

A portion of my time these days is spent evangelizing the Web2.0 accessibility solution: WAI-ARIA (for Accessible Rich Internet Applications). In 2007 I had a lot of fun working with Becky Gibson, Simon Bates, and others to make the dojo toolkit widgets (dijit) fully accessible with keyboard control, high contrast mode support, and ARIA semantics. In the end we ended up doing a most of the code, and the testing, ourselves. We knew even then this was not ideal and what is really needed is to make accessibility part of the core widget design and creation process. If not that, then at least to engage a few core dijit contributors, ones that have been around a while, and will stick around in the foreseeable future. Becky, and another colleague of mine, Joseph Scheuhammer continue the Dojo accessibility effort now. Dojo accessibility is still healthy.

Now it is 2008, and I'm onto a new project, with a role that essentially boils down to: help glue a viable ARIA ecosystem together -- connecting browser, toolkit, and AT (assistive technology) efforts. One piece of this puzzle is helping the jQuery community add ARIA semantics into jQuery UI. In this particular effort I am enjoying working with my colleague Michelle D'Souza who is also busy keeping the Fluid team engine running with her agile-fu. What is different this time is that we are trying our hardest not to dive in and write the code, and to avoid being perceived as the accessibility silver bullet.

Enter Scott González, respected jQuery UI contributor. In tackling ui.dialog we worked with Scott (and to a lesser extent Paul Bakaus), to add keyboard and ARIA support. With Scott's help we put some basic support for ARIA into ui.core, and added a role of "dialog", and aria-labelledby property that points to the dialog's title ID. This means that when focus goes to the dialog, a screen reader will announce that focus is in a dialog, and the user can query for the name of the dialog. Two function calls and we go from zero, to full accessibility. What is important here, is that Scott was keen to jump in on this work, and in the end he came away with an understanding of ARIA (and we came away with a better understanding of jQuery UI).

It would be relatively simple for us to go ahead and add ARIA semantics to the rest of jQuery UI, but we shouldn't. We absolutely must be patient and it is paying off. Scott is helping organize the jQuery ARIA effort, which is awesome! Equally awesome, the filament group is joining... but more on that later.

Thanks for reading.

Mozilla DevDays Toronto

On Monday and Tuesday I attended the Mozilla DevDays Toronto event. This blog isn't so much about the content (which was video taped for later posting) as it is about the essence of my reaction to the event.

In a nutshell, Mozilla DevDays Toronto was extremely valuable to me. All the talks I attended were good, but as is so often the case, I found a lot of value in hallway conversations and breakout meetings. Asking key Mozilla people my half-baked questions in person miraculously ended in fully baked answers, with icing and sprinkles. I'm thinking half-baked questions have to be delivered in person. Mark Finkle thanks for the tips and demystifications about distinguishing XUL dom events, and about XPCOM wrapper decisions.

Day two's talks on automated testing were an awesome introduction to xpcshell, mochitests, chrome tests, asynchronous tests, and ref tests in Mozilla. Note there is an extension developer addon that has an xpcom-ready JavaScript shell (or you can use xpcshell from the command line if you build Firefox yourself).

It was great to see timr again, and to meet jono, mfinkle and others; faces to names as they say. (Tim and Jono ended up touring my workplace today, where we showed them Assistive Technology and chatted about Ux design, automated testing and QA. I'll post on that when I upload my pics off the camera.)

Let's not forget humph! Thanks Dave, I know these events take a lot of effort to pull off, and I want you to know that (at least from from my angle) you put on a high value event!

Thanks for reading.

[UPDATED to fix a name. Sorry!]

Google's Browser?

It seems Google has an open source browser project.

I believe this must be true because a comic strip on the web told me so. While I was reading this comic I wasn't sure what amazed me more, the interesting things I was learning about the technical design of Chrome (the Browser), or the fact that I was enjoying learning about the technical design of Chrome from comic characters.

Is Chrome accessible? Although there was a lot of information about V8, the JavaScript VM, the comic didn't tell me if it had WAI-ARIA support for JavaScript+DOM+CSS based web applications. I was really hoping to see a T.V. Raman, or Charles Chen comic character.

Seriously though, it sounds like the rendering is to be done by Webkit, so perhaps too, the exposure of ARIA semantics in the DOM to desktop Accessibility API will eventually come from Webkit. Of course Firefox has pioneered this stuff, but Aaron is helping the other browsers as much as he can. Today, ARIA is a crucial piece of pushing the web as an application platform.

Thanks for reading.

W3C internal ARIA drafts now public

In April I joined the Protocols and Formats Working Group (PFWG) at the W3C as an "invited expert". In joining I gained access to the internal ARIA drafts. I'm pleased to participate and am particularly happy with our recent decision to go public with our internal drafts: WAI-ARIA, and the WAI-ARIA Roadmap.

But... these are not like the regular public drafts, so please be sure to look for disclaimers as noted in this email: Updated WAI-ARIA Editors' Drafts Now Publicly Available.

Now, let's all get ARIA 1.0 wrapped up soon!

Thanks for reading.

Accessible Web Interactivity Today!

You can use ARIA to make your DHTML accessible today.

I'm still seeing discussion about old techniques for JavaScript accessibility without any reference to the new draft WAI-ARIA specification and best practices guide. I find this alarming, and I can only conclude we need to do a better job at getting the word out.

WAI-ARIA provides a way to give semantic meaning to the DOM nodes which make up your DHTML user interface. Add ARIA role, property and state information appropriately and your DHTML widgets become accessible to assistive technology such as screen readers, and your whizbang Web2.0 application can reach that many more people. It is just good business sense.

The main browsers and JavaScript toolkits are adding support for ARIA. Let's move forward!

Safari/WebKit Accessibility News

Progress!

Keyboard: It looks like we're getting that much needed DHTML/Ajax keyboard support for Safari/WebKit. Thanks go to Alice Liu et al. for making it possible for us to set tabindex on any DOM element. [bug 7138]

ARIA: WebKit has also joined Firefox2+, Opera9.5+, and IE8 in adding support for WAI-ARIA, the W3C draft specification for making DHTML (Ajax) accessible. Thanks go to Beth Dakin et al. for the initial implementation of basic ARIA roles. [bug 12132]

In related news, I had a nice chat with Alp Toker late this afternoon over on #a11y (irc.gimp.net). He's going to donate time to help drive the work on the Linux accessibility atk/at-spi backend for WebKit. Alp is a WebKit/GTK+ ninja so this is outstanding.

I appreciate the heads up today Maciej.

Thanks for reading.

Firebug 1.2 alpha on FF3

Updated:
Someone kindly told me that I had a stale firebug! Go here for the latest.

I recently managed to get an alpha firebug (1.2.0a7x) working well on FF3 by also installing the Web Developer add-on and restarting. I've confirmed that this workaround also helped a colleague (using a more recent 1.2.0a22x of firebug). The workaround doesn't appear necessary for 1.2.0a23x. In other words, this post is obsolete. Sorry for the interruption.

Thanks for reading.

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.

Uniquely identifying chunks of UI

To follow up my last post, ARIA's templateid allows a finer grained customization than what Greasemonkeys, JAWS scripters, Orca scripters and others might be used to.

Normally AT customization happens based on which application currently has focus, and in the case of browsers, which URL is currently loaded. Now we can go inside the document.

We can mark a piece of our UI like this:
<div aria-templateid="abc123.org/FooComponent_v1">
    <!-- embedded FooComponent_v1 -->
</div>

Here's how I imagine it will work: when focus moves within this div, the user agent notices this and fires a platform accessibility event. This event ultimately notifies, for example, a screen reader which then checks for a customization script for FooComponent_v1. This script might offer keyboard operation enhancements, instructions on how to work with a FooComponent_v1 or anything else really.

Like many innovations at the edge, I suspect this will empower exciting and perhaps unintended use cases.

Note: there is discussion about renaming templateid for the final ARIA specification. It is fascinating witnessing the web push the boundaries of how we conceptualize an "application", "module", "component", or "widget".

Thanks for reading.

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.

Revival

I'm officially back to work now, and will be on campus at the ATRC Research and Development Lab Monday, February 25th.

For now, the bulk of my time will be mentoring and hacking on JavaScript accessibility in both dojo and jQuery; with some time reserved for our mobile applications project, and, of course, GNOME!

Riley is seven weeks old and smiling, sometimes.

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.

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.

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.

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]