As a web developer, there’s little I dislike more than building sites to be accessible. Making sure we don’t build dependancies on JavaScript, making every widget work with a keyboard and not just a mouse, making sure that everything can resize without the layout breaking; it’s all a royal pain in the backside. Get it wrong and make a mistake and a whole bunch of ‘experts’ (who don’t even rely on the technology themselves) will whinge at you something awful.

We still do it, however, and we do it because it’s the right thing to do. Like paying taxes or putting the trash out, there are things we do in life that aren’t much fun but are incredibly important. Fail to do them and our collective quality of life is diminished. So as much as I find it an unpleasant chore, I’m firmly committed to building sites that can be accessible as I can make them.

The cost of this can be high, however, and the source of the cost is twofold. Firstly we need to consider the time it takes to thorough implement and test features in an accessible way. Whilst it’s true that a straightforward site build shouldn’t (and if done well, doesn’t) take any longer to do well than do badly, when we get into more complex UI territory with web apps there is certainly an overhead involved. But that’s fine, it takes time to do a high quality job in any field of work.

The other cost is the cost of progress or the cost of our resistance to progress. In our effort to provide an equivalent experience to all of our audience and to not build dependancies on JavaScript in particular, we have made the implicit decision to limit ourselves to a fairly basic set of technologies and working methods. Shed this requirement, and a whole world of possibilities opens up.

The Magical World of JavaScript

A big challenge we face as web developers is dealing with unknown variables. We don’t know what sort of browser is being used, what its CSS capabilities are, how big the window is, what size the fonts are set at and so forth. Further to this, many of those variables can change once the page has already been rendered – the window can be resized, the font sizes changed and so on.

As neither HTML nor CSS is a programming (or scripting) language, we lack the basic principal of conditionals. In all but the most basic of scripting languages a construct is available to say if this condition is met, do this. We can’t do that in HTML or CSS, despite having many ifs, whys and whats to contend with. As such we have to build very defensively, with a very basic set of options available to us.

Once we’re happy to depend on JavaScript, all this is no longer a problem. Most of the challenges we face working in a browser environment with CSS are trivial to solve because we can measure what’s happening on the page and with the window and manipulate both our markup and styling to respond to the situation. Centre in the browser window? No problem! Equal height columns? Easy!

Of course, there are still differences with how the situation is tested, measured and corrected between different browsers, but these are fewer with each new browser release, and can be centrally addressed and abstracted by JavaScript libraries. After some work, this leaves us with a web environment more akin to that of a predictable and capable desktop application.

Enter Cappuccino and Atlas

This is the space that the Cappuccino framework operates in. The team behind Cappuccino, 280 North bill it as a framework for building “desktop-caliber applications that run in a web browser”. They certainly seem to deliver on that promise, too. Just take a look at their demonstration 280 Slides product – an amazingly desktop-like tool in the style of Apple Keynote. This stuff is mind-blowingly cool.

By deciding to remove the constraint and build with a dependancy on JavaScript, along with doubtless hard work, creativity and programming skills, the 280 North guys have been able to push the technology way beyond what everyone else is able to do day-to-day on the web. They’ve built something that is more like a desktop app than we’ve yet seen on the web. But view source and you’ll see that this really is more than a change in conceptual approach, it’s quite a departure on a technical front, too.

Yesterday at the Future of Web Apps in Miami, 280 North announced and demonstrated their upcoming drag and drop IDE for the Cappuccino framework, called Atlas. It’s worth spending a few moments viewing the preview video over at their site – this really is an amazing piece of work. Just like using Interface Builder or Visual Studio to create the UI for a desktop app, users can drag and drop components into place in a window, set how they behave and bind data and interactions to them. It’s all very cool.

The resulting application is a real departure from what we know today as a web app. View source and you’ll find that the entire thing is generated with that dependancy on JavaScript.

A Different Environment

Let’s say we were to make the decision that’s it’s ok to depend on JavaScript for all the advantages that brings. The few users who have JavaScript disabled will have to enable it, and those who don’t have the option to enable it, well they can’t ride. You could then go ahead and build a really nice interface with all the bells and whistles required.

The important thing to understand about desktop software is that when you place a button on the screen in Interface Builder, the operating system knows it has a button. It has predefined behaviours, it responds to the keyboard and mouse, and there are underlying APIs for assistive technologies to hook into to read and activate the button. On the web we have none of that available for free. If we build a custom widget, even something as simple as a button, we might use a few images for the visual representation and then hook up an onclick event to catch the user clicking on it. If we’re being thorough, we’d also set the mouse over, mouse out, key down, key up and hover states too. What we’d have, however, would still just be some images with events on them, causing them to behave like buttons. The crucial missing part is that nothing else knows they’re buttons. That includes the browser and any assistive technology. Whilst the page might look right, it’s not going to work well outside mainstream use-cases.

A big advantage of using a framework, of course, is that you can solve all these problems once. Desktop software developers don’t need to care about how to build a button because the operating system has figured that out for them. So it must be for the web. If a framework like Cappuccino or any other is to implement its interfaces using none standard, JavaScript-dependant techniques, then it must ensure that those interfaces are fully accessible when JavaScript is available. If we want to use this stuff, we – and I do consider this a collective responsibility – have to figure out how to make it work properly, for everyone. Before we can do that, the guys at 280 North need to accept that this is a necessity.

Shortly after the announcement of Atlas at FOWA, Ryan Carson tweeted that it was going to change the web industry forever. Atlas could, in fact, change the way we develop web apps. 280 North currently have the rare opportunity of determining whether that change is for the better or for the worse.