By Simon Willison

Separate but equal?

By Simon Willison

Manchester United football team have come under fire recently over the accessible version of their website, which offers all manner accessibility widgets but doesn’t contain nearly as much content as their regular site. SitePoint’s Trenton Moss first raised the issue, and has included it as an example in his latest article as well. Accessify also have coverage, and Matt May from the W3C has weighed in as well with an outstanding tirade against this form of bad accessibility practise.

From the above, it should be abundantly clear that separate “accessible” versions of content-driven sites are frowned upon by accessibility experts. However, does the same thing apply to web applications? A great example is Gmail, Google’s new webmail service. Gmail is one of the slickest web applications I’ve ever used, thanks to extensive reliance on JavaScript for everything from loading additional page information without a full refresh to keyboard shortcuts for almost every common operation. Unfortunately, the slick interface comes at a high price: the site breaks nearly every accessibility rule in the book.

Would it make sense for Google to provide an accessible alternative version of Gmail? As it stands, the service is inaccessible without a modern desktop browser. An alternative entry point could still provide full access to the data contained within a Gmail account, but without the many interface enhancements that simply can’t be supported by non-JavaScript user-agents. It seems that the arguments used so convincingly against Manchester United’s accessible version are far less relevant when considering an alternative webmail interface; after all, multiple email clients have been available for talking to the same IMAP server for years.

I’m going to ping a few of the accessibility experts mentioned above and see what they think.

  • Matt May

    I once worked for two online grocers, and designed a secondary site for one of them (though it encompassed “downlevel browsers,” phones, handheld devices, people who hated the interface and so on as well). But at the time, I had run up against the limits of what technology could do. Read the link below to find out why I don’t consider myself a hypocrite:

    But as I said there, that was five years ago, and the design practices and tools we have now make it an awful lot easier to create a unified site.

    Gmail is still just a baby. It’s going to learn some things over time about its interface and how best to represent it. Already I imagine they’re feeling pressure from mobile users (as we were feeling in 2000) to make their site usable.

    The last thing most users with disabilities want to see is, “Dear disabled user: we have made an inferior site for you so you’ll stop complaining to us. Good luck finding it, and have a nice day.” Gmail at least gets that much, saying, in effect, “we think your browser is too broken to work with us, but you can try anyway.” While imperfect, it’s a step up from “go away.” But I think they can continue to work on ways to degrade gracefully, while still providing the level of service they have now.

    I don’t think there’s an easy solution today. It will take documented expert advice to get people to change their practices. At the W3C Web apps workshop, I said scripting is overdone. But each time the same thing is reimplemented over and over again (e.g., DHTML menus), it’s a vote for codifying it in a spec. What we need to do at this point in the Web is to take a look at the frontier, and where the foot paths or wagon ruts are the deepest, that’s where we should start laying down pavement.

    I’m banking on a long-term vision of a Web applications language/architecture to codify at least the basics of a Web user interface. The biggest problem with Web apps to assistive technology is that there are 1,000 different ways to design a single thing, and they all tend to leave semantics out of it. If we could create new elements to describe the way people are actually creating the Web, all of us would be better off.

    In the interim, there are the JavaScript accessibility techniques and code samples that we’re working on. I think one of the biggest missing pieces here is a body of work that explains what is good or bad for accessibility. We seem to have too many people saying “no, never, you can’t make JavaScript accessible,” and blanket assertions like that tend to be ignored. Part of this is on us to fix, to show exactly what is possible in 2004.

  • Hmmm… that’s a tricky one. One of the reasons I so strongly object to the Man Utd website is that it wouldn’t be difficult to make the main website accessible; in this case there really is no need to have the separate version.

    I’ve always said web accessibility isn’t rocket science and I’m sure Man Utd might be able to scrape together a few pennies for an accessibility consultant (who’ll probably be a thousand times cheaper than Wayne Rooney). Their website isn’t complex and they can keep it exactly the same and still have it accessible.

    And when I say accessible, I don’t necessarily mean fulfiling AAA requirements and doing user testing with blind and disabled users (that would be ideal but is obviously very expensive). I just mean doing everything that’s reasonable for them (in terms of time and money) to improve it’s accessibility (and ultimately its usability and SEO).

    With something like G-mail, on the other hand, well there’s obviously a lot of advanced functionality going on there with JavaScript. If there’s no way round this well then maybe they should make a separate simpler version.

    That said, in my opinion they should still make every effort to maximise its accessibility because even if it’s not perfect every little bit helps. As Matt says, Gmail is still just a baby so let’s see what unfolds in the future…

  • About a year ago I was bemused my various people thought the Manchester United football team site was considered a shining example of accessibility and I still am.

    Like many websites that create so-called accessible/text-only versions they tend to only consider a narrow group of disabilities and thus get tunnel-vision and shoot themselves in the foot by segregation of the site.

Get the latest in JavaScript, once a week, for free.