HTML 5 is the first time where people with disabilities are at the language development table at the same time as everyone else and I think the reason things have gone a little wonky is that we aren’t used to being at the table at all or we show up to the table a decade after everyone has left (Windows and AJAX are both good examples). There are two very different cultures learning how to work together. It’s exciting and frustrating to watch.

For example, Ian suggesting that aria could be incorporated after Last Call stirs up a lot of history and emotion. We’ve seen it happen far too many times where accessibility is thrown out for the sake of progress and it’s nearly impossible to catch up if we miss that initial window. (While some people seem to be assuming a Second Last Call is a given, there is no guarantee.)

In terms of the canvas element, we’ve already missed the window. canvas is implemented in Firefox, Opera, and Safari and several applications exist that are not accessible such as bespin. I’m heartened by the quick pace of the work to remedy the situation, but it’s hard to tell how it will play out.

Here are the things I’ll be watching and hoping for with the spec in general:

1. As of last Friday’s Canvas Accessibility Task Force meeting, folks at Apple (Doug and James) are working on a prototype that creates a limited object model with aria attributes. I’ll be interested to see what information will be available to access technologies, how that information is provided, and how someone will interact with it.
2. One of my biggest concerns with canvas is that current implementations use JavaScript to draw pixels and there are no objects or nodes to which you can attach aria semantics. I’m hoping that object-oriented JavaScript libraries (like Objective-J) build in aria and that people will use these instead of just drawing pixels. Folks are talking about creating “shadow DOMs” (or shadow trees) that sit behind or beside a canvas. While I’m happy for a solution that will work, that one doesn’t seem to be directly accessible. There’s a lot to watch in this area to ensure we don’t end up with something that looks like Flash circa 1998.
3. I like the direction that the HTML WG and the PF WG are taking in integrating ARIA into HTML5. I’ll be watching for the HTML WG response to Steven’s proposal.
4. The discussion about text alternatives is puzzling. I’ll definitely keep tabs on that, although I have a lot to catch up on to understand the issues.
5. Dare I even touch the summary attribute? [grin] It seems that it was used as a sacrificial lamb to make a process point. While it was intense, the energy and space that were created as a result look promising and I hope are sustainable.

Overall, I think things are heading in a good direction. Having been an editor on two specifications that were fairly contentious, I know it is hard work to find the “right” words that a disparate set of people will be willing to build consensus around. And, consensus is really, really hard. It isn’t unanimous; it’s “what can we all live with.” And since we all have to live with compromise, it isn’t perfect in anyone’s eyes–that’s the most disappointing aspect of specification writing. But, that same compromise is also the beauty because it shows commitment and connection for the future.

So, I’ll keep watching the “HTML5 Reality Show” and hope that accessibility doesn’t get voted off of the island. On the surface the discussion is about elements, attributes and apis, but at its heart it is about everyone’s ability to participate in the future society that will be based on these technologies.

A big shout out to all of you in the HTML 5 trenches. This is really hard work and keep at it. I’m watching, cheering, and jeering from safely behind my monitor. [grin]