When to Incorporate Accessibility

February 28, 2007

Topics: Accessibility, Web Development.

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.

Have something to contribute?

« Read my Comment Policy

6 Comments on “When to Incorporate Accessibility”

  1. 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.

  2. 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?

  3. 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.

  4. 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.

  5. 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.

  6. 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.