All in the <head>

– Ponderings & code by Drew McLellan –

– Live from The Internets since 2003 –


The Cost of Accessibility

25 February 2009

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.

- Drew McLellan


  1. § brad cooper:

    It makes me sad to see accessibility ignored. If only they’d built their app without the complete reliance on javascript, still have it be “of desktop quality” to those that can and do use js, now that could change the way the industry operates. They have the opportunity to set a good example for all other developers, but instead chose to take it in a different direction…

  2. § Rick Curran:

    Interesting article, there’s definitely some challenges to be overcome for these apps. However, with browsers like Chrome which are intended to provide a great experience for web apps then hopefully there will be some consideration for an easy way to create hooks for assistive technologies. The 280North guys have done some amazing technical work getting these apps to work so hopefully they’re up for the challenge.

    @brad cooper: I think at the moment the forefront of web apps is being pushed by apps like these so there’s a lot to be said for the fact they’ve made it possible at all! I can’t see how it’s possible to make a web app ‘of desktop quality’ without using Javascript, it’s a fundamental requirement for these types of web apps I would say.

  3. § bruce:

    Does the app make all its IDE in javascript, or do you mean that the site it outputs is all javascript?

    WAI ARIA exists to make look-a-like widgets behave like native o/s widgets (so a div that is scripted to look like a slider is actually reported to assistive techology the same as an operating system slider). It’s being added to most of the JS libraries at the moment, but still needs human decision-making and intervention sometimes.

    But it’s sad that in order to make it easy for developers (drag and drop and all that jazz) and to achieve the presentational effects you mention (centre in the browser window, equal height columns) all markup, search engine discoverability and principles of graceful degradation are sacrificed. (Assuming I’m correct in reading that Atlas spits out javascript rather than html).

    I’d rather the thing generated html that laid out its UI with tables to compensate for CSS inability to do vertical centering or equal-height columns.

    Or you might as well build the whole thing in Flash. That at least has widgets that map to native UI components automatically.

    But it reinforces what I’ve been saying lately: we need the specs for html 5 and css 3 to be completed and implemented quickly, otherwise developers will go for the path of least resistance, be that Flash, Silverlight or pure-JS implementations.

  4. § Ben Ward:

    I ranted yesterday about Cappuccino, mainly because reading their “about page”: summarises everything I consider wrong about ‘Web Application Frameworks’. They’re providing something which by design bypasses the entire web stack, and I think their philosophy is misguided.

    I don’t for a moment wish to disparage the technical achievement of Cappuccino. It’s mind blowing work, and beautiful to boot. And I said yesterday that the web does <em>need</em> crazy experimentation like this. But to see if marketed as a real application framework for people to build real applications with, given its direction, intend and the parts of the web stack that it’s cut out… that just seems misguided. In fact, it’s perhaps even misleading towards non-technical, easily excited people like Ryan Carson, who faced with a glitzy demo like this aren’t to know that this framework cuts out core functionality that you normally get for free with the web as a platform (and with native OS frameworks… and with Flash…).

    Bruce: The stated design goals of Cappuccino are that ‘Cappuccino is not designed for building web sites, or making existing sites more “dynamic”. We think these goals are too far removed from those of application development to be served well by a single framework.’ and ‘With Cappuccino, you don’t need to know HTML. You’ll never write a line of CSS. You don’t ever have interact with DOM. We only ask developers to learn one technology, Objective-J’.

    It’s not just that it doesn’t produce web content in the proper way, it’s that they actually believe the proper way is so antiquated that it should be entirely bypassed.

  5. § Val:

    @Ben Ward: I think your last point misses the, erm, point:

    “It’s not just that it doesn’t produce web content in the proper way, it’s that they actually believe the proper way is so antiquated that it should be entirely bypassed.”

    No, they’re addressing an an entirely different set of websites, ones that really weren’t conceived when HTTP and HTML were designed. Cappucino isn’t for producing web content at all — it’s for producing web applications. So they’re not saying that the proper way (to produce web content) is so antiquated it should be bypassed. They’re saying that if you want to produce web apps you need different tools than those designed to produce web content.

    I think the Cappu guys would say that there are plenty of tools that are good at producing web content, and that’s fine. They’re trying to solve a problem that’s orthogonal.

    Now, there’s a good debate to be had about whether they are really orthogonal concepts — in fact, one of the big lessons from web development is that it can be really hard to separate content from functionality, esp. on a platform where the latter was wedged into the former.

  6. § Joeri Sebrechts:

    I’m a rich web app developer with a background in desktop development. I build corporate web apps. Html5 and css3, even if I had them tomorrow would still require me to build custom widgets. The time investment required to build desktop-like web apps with graceful degradation is uneconomical at the least. There’s a reason the rich and basic front-ends of gmail are separate codebases. The only way to be competitive with desktop development right now is to go the pure-javascript route. Even if html5 and css3 were here today, they still wouldn’t be competitive with desktop development.

    The problem here is not javascript, the problem is weak assistive technology. WAI ARIA needs to be developed in full, well-supported by screen readers, and then it will get integrated into these javascript toolkits pretty fast. ARIA support is already on the roadmap for several of the major javascript toolkits. We need screen readers that don’t just allow us to say “this is a toggle button” (but it would be nice to start there), but also to say “this is a control, that you navigate around in this and that way, and that can be vocalized so and so”. Web toolkits genuinely want to cater to screen readers, if only the screen readers will let them.

    Let’s also learn to discern between web sites and web apps. Sweeping them together under the single name “web content” does a disservice to both. Just like the variety of content produced on the desktop goes from simple spreadsheets and powerpoint slideshows all the way to apps like adobe photoshop, the web is also seeing a broadening of what people are doing with it. You don’t use a single technology to produce all the desktop content, and in the same way you shouldn’t expect to use a single technology to build all the web’s content. For web sites the concept of graceful degradation is going to remain crucial. But for web apps it’s a bad idea. I say that because a user interface for a 120 pixel wide cellphone screen must be fundamentally different from that for a 1200 pixel wide desktop screen. Not just in the placement of the controls, but in the very nature of its logic. Trying to shoehorn all those targets into a single front-end codebase is a fool’s errand.

  7. § Peter Bowyer:

    I feel the pain and agree with you. But from a pragmatic point of view… my clients don’t give a s*** so long as they get past the legal requirements of accessibility. And if an inaccessible pure-Javascript (or Flash) app is going to make them money then they’ll go for it. And usually, after a few twinges of conscience, so will I.

    How do you address that side, when there’s a business case for doing it? Sure, a business case doesn’t make something “right”, but it’s a strong and powerful arguement that needs combating.

  8. § Richard Conyard:

    @Bruce what is wrong with Flash and Silverlight from an accessibility angle? Potentially is is time to move away from technologies based on the document metaphor to deliver the type of functionality that people want from web apps, doesn’t mean they can’t be accessible though.

  9. § Richard Northover:

    As Joeri Sebrechts just said, “The problem here is not javascript, the problem is weak assistive technology”. Couldn’t agree more. A major reason why developing properly is “a royal pain in the backside” is because there are so many unpredictable problems with JAWS and the rest, and they make it next to impossible to build a clean set of progressive enhancements.

    It’s possible to use advanced CSS because we have reliable ways to make Netscape etc. ignore it, and fall back to the nice semantic HTML underneath. Because there’s no easy way to know what assistive tech is being used (or even check for capabilities) the same can’t be reliably done with JS. If this problem is going to get any better, there has to be the same kind of revolution in assistive technology as there has been with standards-compliant browsers, and the tools we have to avoid confusing older browsers. Tricky one. (And, of course, assistive technology means more than just screenreaders… <brain explodes>)

  10. § bruce:

    @Richard Conyard – Like I said, Flash beats native HTML from the perspective of reporting web app widgets (sliders, meters, accordian menus) etc as native UI widgets. That’s what WAI-ARIA is just starting to do for HTML.

    But Flash is only accessible (AFAIK) on Windows. And is not an open standard.

    Silverlight, I have no experience of.

    I agree “is is time to move away from technologies based on the document metaphor to deliver the type of functionality that people want from web app”. That’s why I like HTML 5 over XHTML 2 and wish the arguments would hurry up and conclude so we can have the damn spec and implementations yesterday.

  11. § Ross Boucher:

    @bruce There are two problems with waiting for HTML 5. The first is that, fundamentally, it still is a document technology. They’re trying to tack on a whole bunch of dynamic functionality to the same document architecture that’s been around the whole time. This is the wrong approach. But even if it wasn’t, the more important fact is that HTML 5 isn’t going to be finalized anytime soon, and we’re not going to see it in Internet Explorer in the next five years. In other words, at least 50+% of the world won’t be able to use the features in HTML 5 for quite some time, if ever.

    @Richard Northover I completely agree.

    I wrote some thoughts on the subject, if you’re interested:

  12. § John Foliot:

    Joeri Sebrechts wrote:
    “Let’s also learn to discern between web sites and web apps. Sweeping them together under the single name “web content” does a disservice to both. Just like the variety of content produced on the desktop goes from simple spreadsheets and powerpoint slideshows all the way to apps like adobe photoshop, the web is also seeing a broadening of what people are doing with it.”

    The problem with this statement of course is that it confuses the real issue – allowing users to interact with information (data). “Web Apps” are half-tools that want to use the browser layer as the GUI, and there is nothing wrong with that so long as you accept that all users don’t necessarily need or want the G in their UI (or conversely, they need or want an alternative G in their UI). So building your ‘web app’ needs to keep this in mind. You can paint it any color you want, but the broadest concept fueling the web is the exchange of knowledge and data over the network, and to argue that web apps are somehow ‘exempt’ from the need to ensure accessibility because they are somehow different does the real disservice here – they are simply more complex abstract layers between the data and the user.

    All of the major operating systems today have Accessibility APIs native to the OS. If you were building a traditional ‘app’, it would talk to these APIs – meeting Adaptive Technology half-way. For ‘web apps’ to truly succeed then, we need to ensure that this dialog continues – which is not always the case. Yes, ARIA is extremely important, as it is probably the best path forward here, but the responsibility also lies with other bits of the puzzle: specs that demand, not suggest, that the dialog with the accessibility APIs exists, and education and understanding of the web app developers that the world is far more complex than drag and drop.

  13. § Conrad:

    Would it really be that easy to define what makes a webapp opposed to web content?

    Is a form tag enough to call it an application and go JS only?

    Bruce’ comment got me thinking, as his would have been my typical arguments.
    I wish more actually affected people would join into this discussion, as I am slightly worried that many of us just got kind of comfy in the “everything has to work without JS” position – and then pull out the “you know it means better SEO too” point. Maybe we just didn’t find enough arguments why webstandards or semantics should be used even if disabled people do not complain and search engines would index JS (don’t they do that yet?).

    Don’t get me wrong I’d love to start with a simple form for everything, and progressively enhance it to a great webapp, but what if nobody really cares? Practical question: Should webdevelopers ask designers for two versions of the layout (one basic, non JS and one with JS or Flash enabled)? And why? Please just remind me ;-)

  14. § Five Minute Argument:

    “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 you use an input with a type of “image”, is that not enough to tell the browser/OS that it’s a button? Moreover, if you attach an onclick event to any element, is that not enough to determine it’s a button and should be added to the tab order, etc.? Not to say that 280 North have done this, of course.

  15. § Rob Landry:

    Great post. Just want to say that I agree that we can’t forget accessibility as we develop these highly interactive Web apps/frameworks. It’s easy to get carried away with all this Ajax-y coolness.


Work With Me logo

At we build custom content management systems, ecommerce solutions and develop web apps.

Follow me


  • Web Standards Project
  • Britpack
  • 24 ways

Perch - a really little cms

About Drew McLellan

Photo of Drew McLellan

Drew McLellan (@drewm) has been hacking on the web since around 1996 following an unfortunate incident with a margarine tub. Since then he’s spread himself between both front- and back-end development projects, and now is Director and Senior Web Developer at in Maidenhead, UK (GEO: 51.5217, -0.7177). Prior to this, Drew was a Web Developer for Yahoo!, and before that primarily worked as a technical lead within design and branding agencies for clients such as Nissan, Goodyear Dunlop, Siemens/Bosch, Cadburys, ICI Dulux and Somewhere along the way, Drew managed to get himself embroiled with Dreamweaver and was made an early Macromedia Evangelist for that product. This lead to book deals, public appearances, fame, glory, and his eventual downfall.

Picking himself up again, Drew is now a strong advocate for best practises, and stood as Group Lead for The Web Standards Project 2006-08. He has had articles published by A List Apart, Adobe, and O’Reilly Media’s, mostly due to mistaken identity. Drew is a proponent of the lower-case semantic web, and is currently expending energies in the direction of the microformats movement, with particular interests in making parsers an off-the-shelf commodity and developing simple UI conventions. He writes here at all in the head and, with a little help from his friends, at 24 ways.