Accessibility is seldom just up to the interface developer

When developing a web site, amongst the initial questions is what level of accessibility one wants for it and what eventual extra measures are needed to achieve that. Sure, if you’re an experienced interface developer, you naturally write semantic HTML, use alt texts and try to avoid making the web site in question JavaScript dependant, and so on.

But, let me tell you something: you can be the best damned interface developer in the world and then still, in the end, you stand there with an inaccessible web site. What happened?

The threats

When it comes to proper HTML, that’s normally not a problem. But the biggest threats to creating an accessible layout are three things:

  • Decision makers
  • System developers
  • What technology/framework you use to create the web site

Why are these threats, you ask? They don’t code the interface, what harm can they do?

The problem almost always comes when we talk about JavaScript features in the web page. It usually starts with someone responsible who wants elements to be shown or hidden on-the-fly, or throw in the popular thing of the day: AJAX. If you’re a frequent reader of my writings, you probably know that I love coding JavaScript and adding all kinds of cool stuff. So, what am I bitching about?

Why is JavaScript dependency bad

My posts What is accessibility and AJAX, JavaScript and accessibility explain my stance and how to develop a web site in a professional manner, but simply put, it’s about reaching as many users as possible.

And if that’s not motivation enough for you, think about how your SEO will suffer from it when Google can’t index all your content properly = lower search engine ranking = less customers = less money. That should make your managers listen a bit more closely to what you have to say…

Why can’t you an interface developers make it accessible on their own then?

The natural place to begin with is, of course, unobtrusive JavaScript. But when we talk about dynamic updates on the web page, or some AJAX calls, there has to be some fallback when the web server can return different states of the web page. For instance, just some text for the AJAX call, or the complete web page + the new content for non-JavaScript users.

And if the system developer/-s and/or the manager are under the impression that this will take just one minute more to develop, they will refuse and stop any such attempts whatsoever. In my mind, it shouldn’t take any longer at all, but it’s about building a back end correctly from scratch. If you haven’t, of course it will take more time.

And once the whole web site is delivered with numerous JavaScript dependencies, it is rarely a small feat to one day make it accessible. So, build it wrong day one and you will definitely pay in the long run.

And the problems with frameworks?

My pet hate object here is the Microsoft .NET framework. On the server-side, it is very competent and the separation of C# code and HTML code is very good. But, the cornerstone of the .NET framework is about a way too tight tie-in to the generated interface code, and it just begs of you to make your web site totally JavaScript-based.

Don’t get me wrong, you can develop an accessible web site with .NET, but the easy path (and the one most system developers seem to choose) is about superfluous markup, JavaScript dependency and a form element that surrounds all the code in the web page (and for those who doesn’t realize it, several forms in the same web page is often very practical).

How to address this

Unfortunately I don’t have an easy answer or golden path for you here. You can argue about how making a web site accessible is the right thing to do, that everyone should want to reach as many end users as possible, that SEO will suffer remarkably; basically you can list all the arguments where each one, in your mind, is a given winner, you can be blue in the face from trying to convince the customer that they should get the best web site possible (one would think that this should be in their best interest), but in the end they just shoot down your arguments and do what they think is best.

If this happens, don’t give up. Deliver the web site as good as you can anyway, because, hell, I want you to be proud of yourselves. You’re interface developers, and it’s your duty to do a good job! All the positions of poor interface developers are already taken, anyway…


  • Geeez Robert … here you go again with the .NET bashing … and I take offence. Accessibility, web standards and usability have nothing to do with the platform you are developing on … nothing!.

    It is solely up to the developer if he/she wants to follow the current standards.

    I like the way .NET makes things easy for new developers to start out with dragging objects onto pages and see how they work. Granted, they spit out horrible code (especially VS 2003, VS 2005 does a much better job). But not everyone is an expert, and it’s a great way of getting started.

    So … enough with the .NET bashing 😮

  • […] makers System developers What technology/framework you use to create the web site Quelle: “Accessibility is seldom just up to the inter […]

  • Hear hear!

    It's very difficult indeed to build an accessible website in a team where not everyone is like-minded (and of course there are deadlines, horrible deadlines..).

    Funny you mention the ASP thing, just an hour ago I was talking with a server-side developer who worked out a pretty ingenious Content Management System (who wanted me to assist him in client-side development), and it contained nearly everything you talk about:

    – Javascript dependencies,

    – Everything's contained in a form-element

    I love projects where I'm both responsible for the client- and the server-side. When everything's in my hands, I can do everything in my power to deliver an accessible website.

    Good article, Robert 🙂

  • Robin says:

    Árni – it’s not .NET that's the problem, it’s Visual Studio and it's god-awful attempts to build what could only loosely be called web pages. A from round everything? Don’t make me laugh.

    At my company be use .NET but we use it in the right way: purely for logic. Page builds are handled through XSLT.

  • Ã&Acirc says:


    That is exactly what I was saying … this stuff is purely up to the developer … I work propably 60% in VS 2005 and 40% in VS 2003, and 2005 is sooo much better.

    I have always liked XSLT … worked with it a lot in the past, it's a great way to do some good presentation layer stuff.

  • Robert Nyman says:


    I know you don't like that and we've discussed it before. But how many environments, for instance, offer something like <code>Autopostback</code> as an attribute to add to your elements to immediately make it JavaScript dependant?

    Naturally it's up to the web developer in the end, just as I state in the post. But I think my main opinion about it still stands: .NET and Visual Studio (as correctly pointed out in the comments above) per default just lures you onto the path of JavaScript dependency, a <code>form</code> around everything in the page and so on.

    I've worked with a lot of different .NET web developers, and I can count on one hand the number that knew of/cared about making it accessible , instead of following the wide path .NET offers you. Just as late as yesterday I got a question from one of them why one would want JavaScript code, and JavaScript events applied, from an external file…

    But it's not necessarily all their fault either, it's about the mindset Microsoft used from day one when they developed it. But it is getting better, so there's hope at least.

    Oh, yeah, XSLT rocks, by the way. 🙂




    Good point, and good work.

  • Johan says:

    So if you would XSLT (stylesheets for XML to say it popular) for the presentation layer you circumvent accessibility issues with Visual Studio and .Net?

  • Stephen Hill says:

    I have to agree that .Net, by design, produces horrible code, but only if you use Visual Studio and/or their server-side controls.

    I write in .Net C# (a wonderful language) and I don’t use VS, I use UltraEdit and I don’t implement server-side controls, I write my own markup and functions.

    This, I find, give me greater exact control over the output of the code. Sure it might take a few minues to write a function that handles select boxes correctly, but in the end there is pure valid accessible code.

    Once the server-side code has been produced, I can then add JS over the top 🙂


  • "In my mind, it shouldn't take any longer at all,…"

    I don't understand how it doesn't take any longer to provide server-side *and* javascript enhanced interface designs?

    When I provide progressive enhancement to forms or features it takes longer for sure. I have to replicate the server-side functionality using javascript, which takes a significant amount of time.

    But I totally agree and in my experience, you can hand a project manager/dev team a working tech demo of (imo) accessible HTML, CSS and framework design, and they STILL return a table based, image-ridden, inaccessible mess as the final site… It has a lot to do with the desire to achieve 🙁

  • Robert Nyman says:


    If you have a strict XML/XSLT structure in .NET, it is very easy to make it more accessible and avoid the common pitfalls of .NET. But at the same time, it should really be told that it is by no means necessary to go down that road to deliver an accessible web site with .NET.


    Naturally it depends on what scenario we're talking about here, but if the server-side is adapted from get go to take this into consideration, it shouldn't affect project time. For a very simple example, you can take a look at ASK and its example PHP and ASP files.


    That sounds great, although I'm not sure everyone either cares as much as you or have the time/money to do it that way. Still, you have my respect. 🙂

  • Karl Dawson says:

    Amen to that damn <code>form</code> tag. We've just completed a major Intranet project here on a Microsoft CMS / .NET platform. Three things got in the way of me outputting valid code.

    – The framework putting <code>noscript</code> tags in twice for each externally-called js file (and putting them in the head of the document).

    – That damn <code>form</code> tag.

    – The time to iron out these problems.

    Still at least the apps were written as web services and output XML ready for some XSLT-lovin'.

  • Robert Nyman says:


    I feel your pain…

  • […] izing Quality Robert Nyman wrote recently about the difficulty to get buy-in for accessible web pages. His article speaks to a g […]

  • […] Ecco il link all’articolo: Accessibility is seldom just up to the interface developer […]

  • […] Accessibility Is Seldom Just Up To The Interface Developer – Robert Nyman […]

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.