There’s no question that I’m going to advocate incorporating accessibility at the beginning of development in this brief article. I am, after all, approaching this question from the perspective that no site should ever be developed without taking accessibility into account. However, there are unquestionably millions of websites out there which have already failed to consider disabled populations, so building new accessible sites is certainly not the only work to be done.
Accessibility isn’t really all that difficult, in the development stage. If you make a point to take disability into consideration from the very beginning of the development process, the process is hugely simplified. Original development has a lot of advantages — the fact that you’re starting from zero provides room for maneuvering which should make accessibility hardly any more complicated than any other project.
The biggest challenge is awareness — maintaining the hyper-awareness required to consider the huge number of variables which may cause problems for the disabled isn’t easy. But if you prepare a checklist of issues (like this one, for example), you can make huge steps by referring to the list regularly. An intimate familiarity with these guidelines will make it even simpler – avoiding color contrast issues or confusing language are issues you can latch onto very quickly.
But applying accessibility retroactively is a completely different ballgame, and it’s not at all enjoyable.
In development, you can check each design or implementation decision against your accessibility baseline as you go, ensuring a very high level of accessibility from the beginning. When applying the same logic against a completed project — whether you designed the site yourself or not — the refitting process is enormously more complex.
Where do you start retrofitting? As a consultant, the job is relatively straightforward — you just need to find all the problems. But as a developer, you need to also find the source of the problem. Developing an accessible web site is the process of leaving out barriers to accessibility. Retrofitting a website is the process of removing barriers to accessibility. It’s always easier to choose not to build a wall than it is to tear one down.
It’s debatable, ultimately, whether it’s more efficient to fix a project which is broken or to start over. Every project needs to have this question answered quickly, however, since it’s never more efficient to try both. The size of the site makes a difference, as does the choice of technology – a site which was inaccessibly developed in a CMS (Content Management System) is a completely different story from a site which was developed using static files.
Why implement accessibility right away? Because it’s easier to do it right the first time than it is to do it over. And if you’ve already developed your site, the time to start over is now. The longer you wait, the harder it’ll be.
Joe Dolson; March 4, 2007 at 10:35 am
What is it that makes you need static pages? WordPress is definitely the one I use the most, but it doesn’t produce static pages. Using the wp-cache plugin you can reduce the server burden and slow down commensurate with high traffic, but it isn’t really creating static pages.
You can use the CMS (Content Management System) matrix to comb through a wide variety of options and try and find exactly the tool you want.
Brian Laks; March 4, 2007 at 1:19 am
Do you recommend any specific CMS (Content Management System)? Specifically ones that can generate static pages… I’m torn between hand making static pages to try and rank well, and speeding up the process with a cms, though the output might not be as accessible. I guess what I am looking for is the holy grail, free open source cms with static output. Wishful thinking?
Joe Dolson; March 2, 2007 at 11:13 am
I wish that was a “most of the time” sort of thing. However, I’ve had no shortage of experience with projects where they wanted to keep the existing content, organization, and design but convert it to an accessible website.
Personally, I find it to be a kind of fun little puzzle — how to reproduce a design which was built in 16 nested tables using semantic CSS (Cascading Style Sheets).
Nonetheless, from a cost analysis perspective, it’s not necessarily the most efficient way to go.
Jermayn Parker; March 1, 2007 at 5:39 pm
That is true but most of the time when this happens, your doing a whole new re-design of the website and so you get a chance to ‘start a-fresh’ in a sense anyway.
Joe Dolson; March 1, 2007 at 1:06 am
You’re right – it’s not a big deal to subtly change a file. But in many retrofitting projects the changes which need to happen go well beyond a subtle change. Altering the output of a content management system, completely changing the coding style and format…these can be very substantial changes.
Jermayn Parker; February 28, 2007 at 6:51 pm
Is it just me or do people make a big deal out of this when realistically its not that big a deal to subtly change the file? Most of the time, I find I change and fiddle with the file more for the actual client’s needs than for accessibility.