bestkungfu weblog

Mark Pilgrim looked at Google’s new email service, giving Gmail low marks for accessibility.

Google’s is just another entry in the Web-email-as-application paradigm. Microsoft’s Outlook Web Access was an early player in the field: an interface that looked and acted like the worst Windows app ever. Of course, it’s not alone: Hotmail and Yahoo Mail now look much more like applications than the simple front ends they were a few years ago.

We now have (or will soon) three different systems for creating cross-platform Web-based applications: XUL, XAML, and Flex. I know people working on accessibility in all three camps. A fourth group is working on building an accessible architecture around W3C’s DOM Level 3 Events model and a few other specs. The problems are the same all around: all want easy app-like development, and to sidestep the accessibility problems we’re suffering now, such as device-dependent events, and exactly the kind of stuff Gmail does.

One thing is clear to me: Web applications are not the same as Web content, and as the browsers (or, more inclusively, the user agents) and technologies evolve, we’re going to have to deal with accessibility of Web apps differently.

The biggest problem that I have with the Google interface, as Mark describes it, is that it is busy creating another non-interoperable interface for users to learn. I appreciate that they’re working on it, but if Google just adds a few attributes to their current interface, the end result will not be anywhere near as effective for the user as something that was designed for users with disabilities.

We’re now up to 3,480,103 different interfaces at last count. That’s why standardizing UI languages is a good idea: even if XUL, XAML, Flex and the W3C approach end up presenting four different UI schemes, at least you don’t have a new mode of interaction for every site on the Web like we have with Web apps today.

I speak from experience. While I was working for HomeGrocer, and later for Webvan, I had to patch the interface for accessibility. Note that accessibility of online grocers is good business: it enables many users who previously have had trouble shopping unassisted, and it’s nearly free — provided you don’t wait two years to do it.

It was, in both cases, an absolute nightmare. Both sites had frames (four to six of them), and had dozens of major issues, many of which were designed into the system to make it something resembling responsive to “the average user.” Things like using JavaScript document.write() to write out items (which saved lots of bandwidth, at the expense of being unusable by screen readers), and cross-frame scripting to maintain cart contents. (We also suffered for a long time trying to change the behavior of widgets that Web users understood. That was bad usability, and when we fixed it, we made lots more sales.)

What I finally saw as the solution was an abstraction of the functions of the site down to each atomic behavior. Then, the site can be reconstituted into any format you like: basic, mobile, all the bells and whistles, or something that hasn’t been done yet. From that, we could build the interface as it existed, with Java and JavaScript navigation and multiple frames, or a scriptless, frameless approach that was much more usable by people with downlevel browsers or assistive technology. I even prototyped two Palm applications from the same core model. But it never got implemented, because Webvan’s back end was so thoroughly broken as to make this approach impossible.

Now, before I get too deep into this, I need to state clearly that for all but the most complex interaction scenarios, a dual-site approach is unnecessary. If you have several frames and JavaScript flying this way and that for a brochure site, you don’t need a way out, you need a little of the old-time Web standards religion. But if you’re going crazy trying to make your app work like native software, and have built a system that’s heavy on the script, and you can’t get your stupid management to stop destroying your relationship with your customers, you should at least consider designing another, more accessible view into your work, if you can’t provide a nice, abstract interface.

I decided Webvan needed a whole ‘nother interface. And I wasn’t alone in this epiphany. The British grocer Tesco rolled out a similar site. And accessibility consultants almost literally ran away screaming when they saw the horror that was the Webvan back end. It was not possible to do anything but make the original site accessible in theory. No user with a visual or motor disability would ever actually use the final product, because they could have called a friend, gone to the grocery store, shopped, and come home twice before they could actually place their order. And this while sighted users could have done a complete shop in ten minutes.

The traditional knock on this is that it is not consistent with the principles of Universal Design. And that’s true. Users with disabilities or downlevel browsers do their business in a completely different area of the site. It is not the ideal. It is not even recommended, except where no other viable alternative exists. Today, four-plus years later, we have standards-based design, and I feel I could have done a lot more today, not having to worry about the horror show that is Netscape 4. But back then, the principles of UD collided with the limitations of browsers and assistive technology, as well as the simple problem of a site that passes all the automated tests, and still fails the user.

This is why designers and developers need to know more about accessibility than how to find and silence an evaluation tool. With Web applications, it is not only about adding alt this and accesskey that. It is about creating a user experience that makes sense to a large number of users. And that number gets bigger when you take into account the browsers that won’t support all the bells and whistles, and the mobile phones and handheld devices that are being picked up by the millions. The Web is past the age of “this site best viewed at 800×600 and up.”

I think Google has it in them to do the right thing with Gmail. The interface alone is simple enough: folders, message lists, textarea for composing messages, ad section that snoops on you. In order to be at least somewhat accessible, it needs to function without script, and preferably without frames. The amount of server magic required there should be easily implementable by any Google employee: it consists of logical interfaces that work whether they’re driven by a scripted site or not.

So, my advice to the G-men: Design the interface to function with or without script. (Yes, this is possible. Really.) Allow users to turn script on or off. Likewise with frames. (Your users will thank you when they log in from one of those terminals in the mall, instead of cursing your name.) Mark up sections of the site with headers, so they can be navigated by screen readers. Use real HTTP links, and override them (if necessary) with DOM events. And don’t break all the key bindings — unless the user says so.

Hell, do all that, and we won’t even have to write a techniques document for HTML and script in WCAG 2.0. We’ll just link to Gmail. There are so few good examples of really accessible Web apps out there that I’d love to see something good come out of this.

For everyone else who’s gotten this far: As a designer, as a developer, you should always be focused on making a coherent interface at both code and interaction level. You’ll thank yourself when it’s time to redesign. Always remember: you will design this again. Prepare now. In a couple of years, you will have all of these UI languages at your disposal, if you only design your system well enough. You’ll be able to mix and match them, even test them live, if you’ve separated code from front end properly.

For now, though, you’re stuck with crufty scripts and broken browsers and assistive technologies, and a whole lot of testing. This is the fun part. Get to work.

(Hmm. I think I just found my paper idea for Extreme Markup 2004.)