Accessibility: Build it in, don’t bolt it on

Accessibility: Build it in, don’t bolt it on

Mark Magennis made this statement at our last Bootcamp. It was such a powerful and memorable statement that it still resonates with me now.

Grand designs and the cost of change

If you’ve ever watched “Grand Designs”, you’ll understand that it’s not such a good idea to make drastic changes after building has started. Deciding you’d rather live in a bungalow once the second floor is on is going to cost you.

Likewise, retrofitting accessibility into buildings i.e. ramps, lifts, accessible loos etc. is a costly and necessary exercise. With older buildings, there’s little choice

There are now regulations for new builds, from the size of the loo through to the height of door handles and light switches.

This has gone further than just meeting regulations, though. There’s a relatively new approach to the build environment, called “sustainable design”, that ensures that we can grow old in our own homes, and that our homes are designed to facilitate and accommodate us in our aging bodies.

Accessible design for the web

The same concepts apply to the web. The cost of change increases almost exponentially as the project gets close to delivery. So, so if accessibility is not considered early, it becomes prohibitively expensive.

Many project managers and developers will be familiar with the following image, which shows what I’ve been saying – “change late, cost more”.

X axis: project progression time, Y axis: cost. The graph goes up and to the right, late changes are very costly

So how do we change this situation. We want to prevent the above graph, and to do so, I reckon we need to do the following:

  1. Define what accessibility is: for managers, stakeholders, everyone. This could be done by showing user testing video or a live demonstration of someone with a disability trying to use the site. The key here is to make accessibility human and real, rather than an abstract concept. Only then, stakeholders make the connect and actually ask for it on new projects.
  2. Show how to ask for it: knowing what accessibility is is one thing, how to ask for it is another. However, it’s vital that accessibility is asked for at an early stage (RFT), that managers know what to ask for and that it is explicitly included in contract documents.
  3. How to measure it: Finally, checks and balances need to be in place to ensure accessibility is actually delivered. This can be done internally at various stages of a project and towards the end, as a final audit. The key here is regular and independent checks, to avoid the situation in the above graph.

Only then, can websites and web applications be delivered with accessibility built in from the start, adding absolutely nothing to the project costs. Again, best articulated at our last Bootcamp with another resonant quote from Mark Magennis’s repertoire:

Accessible design is good design.

Upcoming accessibility events

  • The Irish Internet Association (IIA) is holding a seminar next Wednesday (9th April) on “Accessibility Explored” which should give attendees some of the basics.
  • At this month’s Bootcamp, I’ll be delving a little deeper and will cover the practicalities of accessibility for web managers – the guidelines, tools and project management tips to ensure that accessibility is built in, not bolted on.

Comments are closed.