Accessibility and Ajax: Progressive enhancement vs. side-by-side UIs

One of the most eye-opening sessions I attended at Adobe MAX last week covered the topic "Building Accessible Applications with Flex." Flash/Flex apps have a reputation for being inaccessible to assistive technologies, but presenters Andrew Kirkpatrick and John Bennett debunked that myth. Using lots of code examples, Kirkpatrick and Bennett actually walked us through Flex apps in a screen reader and showed how to use MSAA (Microsoft Active Accessibility) tools - including insepct32.exe - to make them function properly. The practical, how-to value of this presentation was on par with Derek Featherstone's talk at An Event Apart a couple months ago. The Flex world, it turns out, is just like the Ajax world: If an app is inaccessible, blame the developer, not the platform.

This session got me thinking again about the future of accessibility in a post-Ajax world. The standards crowd will argue that Ajax should be sprinkled sparingly on top of old-school webapps; it should be part of a separate behavior layer, with careful attention paid to progressive enhancement and accessibility. Turn off JavaScript and/or CSS - or use a screen reader, or a mobile device - and your app should still function perfectly.

I spent most of the last two years working on just such an application in my former life as a UI engineer at Orbitz Worldwide. Orbitz's new travel platform, introduced with the relaunch of the U.K. travel site, implements progressive enhancement on a massive scale. It was inspiring and educational to help build a giant ecommerce site with first-class support for web standards and Section 508. After a while, the techniques that make such applications possible become second nature.

That said, progressive enhancement sort of locks you into a Web 1.0 mindset - or at least a Web 1.5 one. It's pretty hard to imagine a full-on desktop-style Ajax app that magically degrades into a plain-vanilla website using the same markup and client-side code The more complex your Ajax functionality, the higher the cost of weaving advanced and accessible functionality into the same components. It's not just development cost; it's also performance cost. We've all seen progressively enhancement sites with a noticible redraw effect when onDOMLoaded fires. HTML form elements suddenly morph into widgets as your JavaScript transforms the original markup into Ajaxy goodness. This effect will only intensify as you move past basic Ajax effects and into full desktop-level functionality. So what's a standards geek with next-generation aspirations to do?

Plenty of developers have come to the conclusion that you should just build a separate, accessible UI. Look at Microsoft Outlook Web Access and Gmail, the two applications that put Ajax on the map. Both of them offer an advanced client and a stripped-down, plain-HTML one. If it worked for them, why can't it work for a lot of sites? Writer Bex Huff outlines the advantages of this approach pretty compellingly. The accessibility gurus at Webcredible have come to pretty much the same conclusions, albeit after a bit more hand-wringing. I doubt the WC3's forthcoming Web Content Accessibility Guidelines 2.0 will provide a comprehensive roadmap, but the draft version does at least acknowledge how much the landscape has changed.

Accessibility vs. Ajax has been a big topic for a couple of years now; my former Orbitz colleage Mark Meeker has earned plenty of kudos for his talks on the subject. But why do so many discussions of the topic still start from the premise that the same client-side code should support all users? I'd be interested to hear from developers of ecommerce sites and full-featured web applications. Are you building accessibility into your application architecture at all? If so, how? Progressive enhancement or separate UIs? Let me know in the comments.

Technorati Tags