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…
