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.