Thursday, December 20, 2007

Leveraging 2^W For Accessibility

A few weeks ago, I blogged about 2^W: The Second Coming Of The Web. That article talked about how once Web content was URL-addressable, it immediately became mash-up ready thereby opening up the way to creating integrated views of that content. Earlier this year, I blogged on Google's Official Blog about how Web-2.0 mashups presented an as yet unleveraged opportunity for providing accessibility across the Web by integrating custom views to present content in a form that was optimized to the end-user's needs. To reiterate --- this is in fact what Universal Accessibility was always supposed to mean --- rather than the somewhat short-sighted view that has become prevalent --- If it works with a screenreader it's accessible.

More recently, my Google officemate Charles L Chen and I have been working on a JavaScript based Web-2.0 framework called AxsJAX for injecting accessibility into Web applications. As an illustration of the ideas underlying 2^W coming to life in running code enabled via AxsJAX, we recently AxsJAX-ed the XKCD comic strip. Here, we bring together the XKCD sketches with the associated transcript to create a mashed-up view where the user gets to listen to the transcript while at the XKCD site. You can most easily experience this for yourself by installing a self-voicing plugin for the Firefox browser.

Note however that there is nothing Fire Vox specific about this XKCD mashup or any of the other AxsJAX extensions; all it needs is a relatively modern Web browser like Firefox that implements W3C ARIA and adaptive technology that has been updated to work with the event notifications raised by conformant AJAX applications.

3 comments:

PhillJenkins said...

What is so short sighted about "If it works with a screenreader it's accessible"? Accessibility is, and has always been to me, so much about all the stakeholders doing their part, and all you have described is enablement for accessibility and labeled it "Universal Accessibility". Let me explain, that; as you stated in the last paragraph: "all it needs is a relatively modern Web browser like Firefox that implements W3C ARIA and adaptive technology that has been updated to work with the event notifications raised by conformant AJAX applications".

So, what you haven't said is that IE isn't yet a relatively modern browser like Firefox because it doesn't yet support W3C ARIA. I agree that Microsoft IE should support ARIA, but my point is that it doesn't yet. So, to all those employees in real world jobs (not high tech ones like you at Google and me at IBM where we can have multiple copies of browsers installed, and maybe even mutiple laptops with Linux, Windows, and whatever), that have to wait till IE supports ARIA, what are they suppose to do? What I tell their companies is that: "If they let them already install nonstandard adaptive technology, then why not let them install non-standard browsers and such too if it removes the barriers to accessibility? The answer is, "Well, who's going to test it all to make sure it works and is supported?" Ah, good point.

You also didn't say that both JAWS and WindowEyes have been updated to support ARIA as implemented in Firefox, and that the Linux Screen Reader also supports ARIA as well. So at least those users who have the permission to install and run Firefox or Linux will be able to benefit from the enablement you describe. With some education, outreach support, and affordability (funding) for the end users themselves, like making sure the user knows how to use mash-ups and configure things correctly, and can afford to make the upgrades - we have most of the right side of the stake holders covered.

Lets discuss the left side of the stake holders (the part before the content is conformant and published on a server). We have the ARIA spec, check, we have the AxsJAX for injecting accessibility, check, and you have described mashing up (bringing together): "the XKCD sketches with the associated transcript to create a mashed-up view where the user gets to listen to the transcript while at the XKCD site", check. But who (developers, service provider, content provider) is going to do all this? Where are the tools and motivations for them?

Today in the Web 1.0 world we have spec for things like alt="text" and XML for adding timed text to audio and video. And we even have a good start at authoring tools and checking and repair tools to help the authors and developers to make the content conform to some basic standards. But where are things on Web 2.0? Even when the suport is implemented in IE, and even when the user has an "updated adaptive technology", somebody has to create the "conformant AJAX" application and someone has to create the "associated transcript", and they have to do it under budget and within the project deadline.
So, back to ""If it works with a screenreader", maybe is simplistisct, but I see it as a test of a more wholestic view because it considers the whole food chain, all of the stake holders, the complete supply and delivery cycle, and [insert your latest buzz word here], because at the end of the day if it doesn't work - its not accessible to the end user!
I do like the title of the post - leveraging Mashups for Accessibility, just didn't want any readers to thinks there is a silver bullet here. Reminds me of the old days when GUIs were first coming out and there was talk about how they were going to make things more universally accessible, or when the Web was introduced, or even proprietary technologies like PDF - my point being that until all the stake holders get lined up and do their part, enablement and leveraging is necessary and great, but not sufficient. If it doesn't work in the adaptive technology, its not accessible to the end user.

Unknown said...

I would also add that, in my experience, persons using adaptive technology will often postpone updating their software until they update their hardware. They do this for a couple of reasons: 1) new adaptive technology software tends to be quite expensive, and 2) installing everything at once helps to insure a common level of compatibility, and a greater degree of dependability.

So, as we march into the brave new world of 2.0 widgets and ARIA-ready applications, let's be sure that we not only create accessible interactive software, but software thats work for people with pre-ARIA browsers and screen readers.

Mike Elledge

Ideation Fashion said...

Nice sharing. learn a lot from this blog.birkin bag