Accessible SVG is closer than you think

[Firstly, my apologies for not blogging more often (blame twitter). I have a number of unpublished blogs that I've let get stale so I'm going try not to save unpublished blogs anymore. We'll see how that goes. Anyways, here's one I probably should have written late last year...]

Sometime in early December, Aaron pinged me to discuss the topic of SVG accessibility. This led to a quick Firefox experiment (tweeted here) using the cutting edge HTML5 parser and WAI-ARIA. Note this demo is especially uninteresting if you don't use a screen reader. Long story short, it works and will work even better with a little gecko love. Web developers that have already invested in learning ARIA can apply this knowledge to SVG elements, add some JavaScript, and have a pretty striking and accessible application. Note: please don't look to my experiment for "striking" visuals... that's just not my thing... you have to use your imagination here.

I wonder, given the momentum HTML5 canvas currently has in the web developer playground, if the ability to inline SVG in HTML will breathe new life into SVG? As far as accessibility goes, it is certainly something for which I can hope.

Oh and if someone wants to fix up my demo, feel free, and please drop me a line... and I'll link to yours. I'm a total SVG noob.

ARIA User Agent Implementation Task Force

Today we kicked off the first meeting for the "ARIA User Agent Implementation Task Force" (UAI-TF). Our primary goal is browser compatibility in our WAI-ARIA implementations for DHTML accessibility -- vital stuff. The group is very lean and today there was representation from browser people at Microsoft and Mozilla.

If you are an Opera, Webkit, or Safari accessibility developer please consider joining us.

Aside: a big shout out for Aaron Leventhal for planting the seeds of this, and for the excellent and detailed document he created to guide browser developers on ARIA implementation.

Call for review: WAI-ARIA

If you are somehow involved in supporting interactive web content, please consider reviewing one or more of these W3C documents related to accessibility.

For everyone involved in web content, this is the document with actual "Last Call Working Draft" status:
Accessible Rich Internet Applications (WAI-ARIA) 1.0 - Last Call Working Draft
http://www.w3.org/TR/wai-aria/

For web application ninjas:
WAI-ARIA Best Practices - updated Working Draft
http://www.w3.org/TR/wai-aria-practices/

For browser developers:
WAI-ARIA User Agent Implementation Guide - First Public Working Draft
http://www.w3.org/TR/wai-aria-implementation/

It is important that these documents are understandable and consistent. The deadline for having an impact via your comments is April 17th, 2009. Official channel is: public-pfwg-comments@w3.org (see this email for details).

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!

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.

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.

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.

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.

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.

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...

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.