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!

Browser Accessibility Acid Test?

We're on our way! Thanks to funding from the Mozilla Foundation, Eitan Isaacson has built a tool for comparing browser accessibility implementations. His latest post titled "Apples and Pairs" provides some examples of its usage.

Thank you Eitan!

My Wordle

What should the alt text be? I think I give up...




Image made by http://www.wordle.net/

Indoor Positioning using Wifi

Have you ever wanted to pull up a floorplan on your mobile device to help you find your way?

Jorge Silva, our mobile lead here at the ATRC, and students Jamon Camisso, and Yura Zenevich gave a lunch talk the other day to show off the state of their Wifi based indoor positioning system. It seems they have managed to get within 5 meter accuracy using existing WiFi points and some nifty statistical algorithms. Jamon is looking at how this technology might tie into geolocation efforts such as Mozilla's Geode. We'll also look at connecting with efforts in GNOME, AEGIS and other projects. Exciting stuff.

Here's the quick upload of the talk in five parts. Captions are coming, and apologies for the lighting.

This work is done as part of the SCYP project and like many innovations is coming from an accessibility angle. I think this work provides a nice foundation for all kinds of student engagement here at the University of Toronto and elsewhere.

Thanks for reading.

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.

Google Health with WAI-ARIA support!

T.V. Raman reports the latest Google ARIA addition goes to Google Health. See also the related article in eWeek. It makes good business sense, and is a good move for many reasons.

Google's approach, of sending ARIA over the wire only when necessary, intrigues me, but I think there must be a better way of automating the decision. Are users comfortable setting "enable screenreader support" as a preference? It seems many people are generally concerned about giving away too much information about themselves...

T.V. lists the key-bindings for using this Web 2.0 application and they look like they gel with the DHTML Style Guide. Nice work Google.

The W3C draft specification: WAI-ARIA continues its emergence as the solution for providing Web2.0 experiences for everyone.

AEGIS! AEGIS! AEGIS!

The AEGIS website is live.

Finally I can tell the world!!! This is that "big project" I've been waiting ages to talk about.

AEGIS stands for: (Open) Accessibility Everywhere: Groundwork, Infrastructure, Standards. Think third generation accessibility meets desktop, rich web, and mobile.

You'll start seeing lots of chatter soon on mailing lists, blogs etc. In a future post, I'll go into more detail about the role the ATRC will play as a Canadian partner in this important work.

Hmmm, I wonder if I'm allowed to use the logo in a blog...

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.

IE8, ARIA, Quirks?

Aaron revives an important issue in his recent post: Legacy defeats consistency in IE 8’s Web 2.0 accessibility effort.

Despite agreement that it would be great if web developers could have a consistent standard way of supporting WAI-ARIA, it looks like syntactically (at least) is out. Browser ARIA implementation (how events, semantics, and structure are exposed to platform API) consistency is yet to be determined. Thankfully there is a harmonization effort built around a shared wiki document: ARIA User Agent Implementors Guide. Please for the sake of all things good...

Aside: Currently "IE8 Standards Mode" is expected to be the "default mode", unless you add a meta tag: <meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" /> or have a doctype that triggers quirks mode. What if you are building a DHTML widget library? What mode are you going to be in? What about mashups? More normalization... sigh... Does it always have to be this way?

Thanks for reading.

Moz@ATRC

Several days ago Tim Riley, and Jono DiCarlo, both from MoCo visited our lab here at the ATRC. As a sort of swearing-in I took them to our services pod where they got to try out some assistive technology. I took a few pics, and decided to try out my free download of Comic Life for OS X. It is a visual tool that is incredibly intuitive and simple to use (but not very accessible I'm afraid).

The first few frames show Jono, and Tim with shiny dots on their foreheads. These dots are picked up by a camera resting on the top of the screen, and allow the operation of the mouse pointer via head movement. We hooked them up with the open source Dasher input software. I think they both got a kick out of trying this and other Assistive Technology. The last frame shows them meeting with more of my group at the University of Toronto, where we discussed QA, automated testing, and UI design in open source communities.

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!]

Capability

On a recent thread over on wai-xtech, T.V. Raman brought up the notion of talking about capabilities instead of disabilities. I like this. I'm reminded of my old post which played with the definition of disability.

Furthermore, a request for adaptation should never have to be a statement about the physical individual. It should be a statement about a preference in context. I want captions when watching television with the volume down, and I want a ramp when pushing a stroller.

GWT ARIA News

Alex Rudnick from the Google Web Toolkit Team has recently posted on the topic of ARIA and GWT 1.5. Specifically he states

To make applications built with GWT more easily accessible, we've added accessibility support to the GWT library by baking ARIA roles and states into our widgets

Great stuff. Not everything in the youthful ARIA ecosystem of browsers, desktop, and assistive technology is fully working; but we'll get there if we all work together.

Thanks for reading.

Join the free ARIA Community

Aaron Leventhal has created a Google group: free-aria (reminder: ARIA is the technology for an accessible Web2.0). This is a great place for working discussions. Please read Aaron's related blog.

We really need people willing to help build and organize our test cases, as well as people with the skills to do the testing.

If you want to help but aren't sure how, feel free to email me.

Thanks for reading.

Google Chromer to join ARIA browser group

Jonas Klink from Google will join the WAI-ARIA browser harmonization effort! This small and lean group, spearheaded by Aaron Leventhal currently meets weekly to discuss the details of how user agents should expose WAI-ARIA semantics and events to the desktop platform accessibility layer. We have representation from Firefox, Safari/WebKit, Chrome/WebKit, IE, and Opera; as well as some representation from JavaScript toolkit ARIA development (me).

The current work is focused on contributions to the ARIA User Agent Implementors Guide created by Aaron. This document captures practical implementation details based on the experiences of the Firefox accessibility developers in pioneering browser ARIA support.

Thanks for reading.

Planet Accessibility!!!

"Blog feeds from the contributors of accessibility through technology."
http://www.planet-a11y.net/

Thanks Bryen Yunashko (suseROCKS), and Flavio Percoco Premoli (FlaPer87), for this fine contribution to our growing community!

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.

Scratch-ing an Itch

I gave a talk a few hours ago at the inaugural Scratch conference at the MIT Media Lab. Having first used Scratch last week, and leaving for the airport at 4am this morning I found myself reflecting...

What am I doing?

The title of the talk is "Scratching All Itches Equally" and originally listed Gregory Rosmaita, Liddy Nevile, and Jutta Treviranus as speakers. Gregory and Jutta couldn't make it so I was asked to jump in.

Here is the description in the program guide:

A discussion of strategies for ensuring that Scratch is usable by all, whether one can see the screen, or use a pointing device or an on-screen keyboard. The goal of the panel is to discuss Scratch’s architectural framework to ensure that it is capable of communicating with operating system accessibility APIs, as well as platform-agnostic APIs, such as IAccessible2 and ATK/AT-SPI (Assistive ToolKit/Assistive Technology Service Provider Interface).

Liddy and I realized that the audience was going to be made up mostly of teachers so we decided to turn the talk into less of an engineering discussion, and more of a brainstorm. We framed the storm in the context of Scratch, and accessibility, or disability in the wide definition.

Over lunch, it was cool to hear people from our talk bringing up topics from our brainstorming to groups who hadn't attended.

What interests me most about Scratch is that it is playful programming that kids (well, not just kids) can pick up rather accidentally in order create and express their ideas. It makes a lot of sense to me that this kind of tool should be made accessible to all children, regardless of culture, gender, or physics. When you only allow a subset of people to participate in creating and making, you lose some of the most valuable and insightful influences; you stagnate.

Thanks for reading.

GOK Maintainership

Here's my recent post to gnome-accessibility-list@gnome.org:

Gerd Kohlberger has accepted the honour and responsibility of helping maintain GOK, the GNOME suite of on-screen keyboards that, among other things, provides access to the entire GNOME desktop via a single switch.

Gerd has already proven himself in the GOK codebase, is a skillful and thoughtful developer, and I think is the right person to help meet the challenges of maintaining a venerable C program beyond its 7th year. I'm hugely thrilled to have his help!

With the help of others that have emerged in the GOK community recently, these are happy days for GOK. A huge shout out to the helpful people who meet regularly in #a11y. THANKS!

This feels good. Thanks for reading.

FF3 is for everyone!

Yesterday Firefox 3 was released. Congratulations to the entire Mozilla community! I'd like to give a special thanks to Aaron Leventhal, and Marco Zehe who have led the work to make this the most currently accessible browser ever, including bleeding edge support for Web2.0 Accessibility through the ARIA draft standard. Kudos also to the extended Mozilla accessibility community. Outstanding work!

FYI: I switched yesterday from being a minefield user to a FF3 release user, but am still using my minefield profile. So far so good; all my developer add-ons seem to be working as expected.

Thanks for reading.

jQuery UI 1.5 released!

Congratulations to the jQuery UI community on this important milestone (see Paul's post). I'm really excited about the next major milestone being being fully accessible with WAI-ARIA semantics! We'll be chatting with Paul this week about getting this ball rolling again. Anyone who is interested in helping out, please watch (y)our jQuery Accessibility (Google Group). Good things coming.

Intel Core2 Extreme 3Ghz

That's right baby... on my desk this morning in the form of a Sun Microsystems Ultra 24! I'm sort of slack-jawed at the awesomeness. I'm thinking I'll configure it for a dual boot with OpenSolaris, and either Ubuntu, or Fedora.

"Code Talks"

If you build it will they come?

http://wiki.codetalks.org/

We need a new logo.
We need authors.
We need advice on organizing the wiki.
We need to figure out what we want this wiki to be.
We includes you.

Thoughts?

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!

What is this thing we call "design"?

Today I attended a lecture by Nigel Cross titled, "Designerly Ways of Knowing: Understanding how Designers Think and Work".

For me, the "take home" stuff came near the end when Nigel juxtaposed his analyses of conventional problem solvers, and great designers. Here are my notes:

Conventional problem solvers:

• tackle the problem in the 'easiest' way
• accept the problem rules
• adopt standard problem representations
• re-use previous solutions

Expert designers:

• tackle the problem in a 'difficult' way
• challenge the problem rules
• construct novel problem representations
• create new solutions from first principles

Where do you fit in?

Mozilla and Accessibility

Aaron Leventhal has started a thread called: "Mozilla accessibility -- collecting stories & dreams". If you'd like to read what folks say about the Mozilla Foundation and its relentless commitment to keeping the internet a place for everyone, check it out.

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.

GNOME A11y Meeting Summary

Here is my summary of our weekly GNOME accessibility meeting:

We briefly discussed the pointer grab issue. Can we deprecate XGrabPointer? Frafu and I are to discuss and take this up with the X people if it makes sense. Frafu will likely carry this torch.

We may be getting another evince task proposal.

We also discussed how to organize the meetings moving forward. During the meeting we will: do GOPA status updates, spend a few minutes to meet any new folks on the channel, and finally, discuss a 'hot topic' in GNOME accessibility.

Where: #a11y (gnome irc)
When: Mondays 9:30am EST (13:30 UTC)

Thanks for reading.

Weekly GNOME GOPA meetings!

Our plan is to meet weekly to discuss GNOME accessibility tasks and share witty remarks. Please join us if you are good at either. There is still lots of work (and money) to share!

Where: #a11y (gnome irc)
When: Mondays 9:30am EST (13:30 UTC)

We met yesterday and ended up discussing magnification. I look forward to seeing Kristian post to the gnome-accessibility-list again about possible magnification work. It would be great to move forward in this area soon.

Go GOPA!

Safari Accessibility

There is a conversation happening about Safari (and WebKit) Accessibility. It all started with a post to GNOME desktop developer list from Maciej Stachowiak. I added the Mozilla Accessibility list in the cc of my reply.

We all seem to be mostly agreeing, I think...

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.

aria-templateid explained

PLEASE NOTE: some time after this post, aria-templateid was removed from the draft specification by the W3C.

I wondered when an aria-templateid might be used so I asked Richard Schwerdtfeger.

Rich enlightened me using Gmail as an example, whereby Google could define a unique template ID URL such as:

aria-templateid="google.com/gmail".

Whenever an assistive technology (AT) sees this template ID it can provide customization to improve the UX. For example, a screen reader like JAWS or Orca could load a script for adding keystrokes to open the Gmail inbox etc. If another web product embeds Gmail the AT can still pick up the the template id and apply some customization.

Thanks Rich. This rocks.

Maybe what's most cool about aria-templateid is that we can think about tackling web accessibility in innovative new ways via customization.

Could we now essentially "Greasemonkey" the interactive DHTML web space, including mashups, for accessibility? I'll try to post my thoughts on this in the near future.

Well, that's enough for now. 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.

CSUN 2008 - my regrets

Sorry to everyone who missed me at CSUN this year. Life got in the way. Next year for sure!

Do bug references taint code readability?

Sometimes we write code that looks slightly odd or unpleasant, but it works around (or fixes) a bug, a bug which otherwise is perhaps beyond our control (e.g. some interaction issue with a closed source tool). We write the code as best we can to make it self documenting, perhaps adding a short comment to describe why the workaround exists. We write an automated test to protect against regressions. We refer to the bug # in the tests for easier forensics should things go awry. We are fashionable.

Yet we are still worried about someone coming along and shredding our unpleasant fix, forgetting about the regression tests, and reintroducing the bug.

Refer to a bug number in a source code comment?

How fasionable is that? I've googled but couldn't find much on the topic. I've seen it done quite a bit in the Mozilla codebase, and I'm inclined to think it has merit in some cases. I wonder what others think.

Anyway... this blog was inspired by a dojo meeting a few months ago. I let it sit unpublished for a while... until a time when I'm mentally exhausted and just don't care what blatherings I post...

Thanks for reading.

ARIA-ized Google Reader

Yes! Nice work T.V. and Charles!

Don't read this. Read the Official Google blog: ARIA For Google Reader: In praise of timely information access

Hmmm. I'd like to see more about how to best use AxsJAX for prototyping. Did you guys find getting things to work using AxsJAX and FireVOX covered things quite well? Or did you then find it a lot more work to get things to sound right with JFW and WE? I haven't really played with AxsJAX much but maybe I should?

Go Google Accessibility!

ARIA on Webkit's R(a)dar?

What does this mean: "rdar://problem/5785134"?

It appeared recently in a comment on the WebKit ARIA bug.

If it is an internal Apple thing how do we keep informed on the status? Tackling this bug would be a great contribution!

Be sure to check out: ARIA UA Best Practices by Aaron Leventhal.

Personalized UI Generation

Working on campus has its benefits.

On Tuesday I attended a talk by Krzysztof Gajos titled: "Automatically Generating Personalized Adaptive User Interfaces". It was nice to see some solid research being done in this area with particular attention to users who have a motor/dexterity impairment. Here are some of my notes which of course may have wild inaccuracies.

Krzysztof seems to have applied theory in mathematics and algorithms, particularly "decision theoretic optimization" to graphical user interfaces. I'm not talking about Fitt's law. Think: AI meets HCI.

For his problem space he considers 3 things to adapt the GUI to:
1. devices
2. preferences
3. abilities

And things to adapt, or "UI building blocks":
A. Layout
B. Widget
C. Structure
D. Size (this last one he added later in his research)

The context seemed to be mouse based interaction in graphical user interfaces.

Treating GUI design as an optimization problem he developed quantitative metrics and a cost function, essentially with weights to be applied to widgets. For those with an AI background his bag of tricks included: branch-and-bound search and full constraint propagation. The "cost" function I think of as a "utility" function (common in game decision AI). Oh and perhaps most wonderful to hear him say was that "deep down it is a constraint satisfaction problem". Yes! I'm sort of known for saying a lot of things boil down to a constraint satisfaction problem and some of my colleagues would have a good laugh about this I think. Anyways, this isn't about me and I've lost track of what this paragraph is for.

He spoke of the geometric concepts that arise from considering each UI preference an axis in a multidimensional space, and that each preference of one UI element over another is a hyper-plane in that space. Overall the 'shape' of the solution space of elements that solve the preference criteria is a polytope. Way cool stuff to think about at a high level.

He mentioned four elements of UI Design:
a. Perceived effort
b. Cognitive effort
c. Motor effort
d. Aesthetics

In analyzing ability, or motor effort, he optimized for time as opposed to preference:
cost(rendering(UI)) = time

So what did I take away?

1. People without mobility impairments found the time optimized generated GUI ugly.
2. Everyone was more performant using their generated time optimized GUI.
3. Krzysztof is someone to watch.
4. The biggest gain in performance was using a widget or widget set that required less mousery to manipulate, for example: a set of 5 radio buttons, instead of a combo box with 5 options.

Krzysztof really made his algorithms quick and it was interesting to see a demo of UI changing dramatically as he changed a constraint, such as screen size. The widgets, and widget hierarchy changed on-the-fly, for example, widget groups became tab panels in an auto-generated tab container.

But no spinning angry face. Sorry... inside joke.

Thanks for reading.

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.

GNOME Accessibility Grants!

Do you care about free software and feel that the functionality it provides should be available to everyone? Do you want to be welcomed into a fantastic community of nice people doing innovative and creative work? Want to help make the GNOME desktop usable by everyone? Want to solve difficult technical problems? Or to write documentation? Would you like some money? Can you get the job done?

More info: http://www.gnome.org/projects/outreach/a11y/

Press release: http://www.gnome.org/press/releases/gop-a11y.html

Uncle Willie needs you!

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.

Orca a-Live Regions

The Orca and Firefox accessibility folks have being working hard together to bring the dynamic web to users who don't use a visual display. Today Scott Haeger announced that Orca 2.21.90 includes ARIA Live region support!

Congratulations, and thanks for all the hard work!

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.