The wheelchair access ramp was blocked by more than a foot of snow…and two potted trees. I was bemused and frustrated at the same time.

One snowy winter day, I went to the pharmacy to buy cold medicine. I couldn’t get into the store.

Pharmacy entrance with snow and trees blocking the ramp

The wheelchair access ramp was blocked by more than a foot of snow…and two potted trees. I was bemused and frustrated at the same time. Bemused because the situation was ludicrous; frustrated because I really needed that Sudafed.

Obviously, at some point, someone made an effort to make the store accessible. And just as obviously, at some point, someone else plain forgot. It’s a more common problem than you’d think.

Accessibility that needs ongoing maintenance all too often leads to failure.

The downward spiral

Another illustration. The city council wanted me to present my analysis of the renovation plans for a civic building. The council chamber was on the second floor of a building with no elevator–incidentally, access to the council chamber was one of the items up for discussion.

To get elevator access, people needed to go to the building across the street, take the elevator to the second floor, and then cross the street again via a skyway. The door to that building was locked after hours. If you needed access, you had to ring a bell and someone would come, open the door, and escort you through the locked offices to the council chamber.

I’d arranged ahead of time to have a security guard waiting for me at the door in time for my presentation. I arrived at the appointed time, but no one was there. I rang the bell, and waited. No one showed up. Half an hour later, I connected with someone by phone who sent someone to open the door…but they couldn’t find the key. Needless to say, I was late for my presentation and the city council’s good accessibility intentions fell way short.

These kinds of things happen all the time both in the built environment and online. We build something, and for one reason or another, we leave accessibility until the end. It’s tacked on as an afterthought, or we rely on third party solutions to fill the gaps. We end up with something that might pass as accessible, but it needs ongoing maintenance to stay that way. The snow needs to be shoveled from the steps and that new ramp. We have to figure out where to store those potted trees in the winter. We have to make sure there’s staff on duty, and that they have the right key. We build forms and modal windows, but when the site is redesigned, these aren’t updated. Or different parts of our sites use different vendor applications that aren’t keeping up with accessibility improvements.

More work for everyone

With after-the-fact approaches like this, there are many small parts, actions, or processes that need to happen consistently in order to ensure accessibility. Each and every one of these parts is vulnerable to failure, increasing the likelihood that the accessible solution ends up not working as expected. We get busy, or the people maintaining the accessibility solution get reassigned to another team. We change something on our site or in our code, but the changes aren’t carried through to the accessible solution. Accessibility slips through the cracks.

In the 90’s, an accessibility solution that got some traction was providing a no-frills, text-only version of a site linked to from the main site. Invariably, after a time, updates made to the “main” site weren’t reflected on the “accessible” site. People relying on finding information on the accessible version of the site couldn’t find up-to-date information, or were unaware that the information was outdated. Not to mention that text-only formats aren’t accessible for everyone—some people rely on visual formats to parse information. There’s also lost functionality when going to text-only formats, so it’s just not a holistic solution. What’s intended as a separate-but-equal experience is, in fact, just separate.

The more you have to prop something up with human effort, the more likely it is to fail. In the words of Dr. Horrible, “The status quo is not quo.”

Integrating inclusion

Solutions that require extra caretaking come from the right intent, but they fall short when encountering real life. They fall down because they’re managed by people. And people are, well, human.

Managing accessibility like this takes a lot more effort than integrating accessibility into your process from the beginning.

The pharmacy owners could have removed the snow from the ramp before shovelling the stairs. Then everyone could have used the ramp. This isn’t the best fix, but it meets everyone’s needs. The better strategy is to build the store level with the sidewalk, and have a no-step entrance providing access for everyone equally. Fix it once, fix it for good.

Cartoon illustration of children talking to the custodian shoveling stairs.

Child in wheelchair with other children standing nearby: “Could you shovel the ramp, please?”
Adult shoveling stairs: “I will as soon as I clear the steps. A lot of kids want to go up.”
Child : “If you did the ramp, we could ALL use it.”

Ideally, your team discusses strategies for creating accessible products right from the first planning meeting. The designer creates a colour palette with accessible and beautiful contrast. The development team contributes to a pattern library, so they’ve always got accessible components at their fingertips. Product Owners create inclusive use cases for product specifications and user stories. And the whole team gets behind testing with real people to make sure your creations work for actual users.

But, more likely, you’re reading this while in the middle of an ongoing project with code and designs you inherited. Maybe you’re the only one on the team thinking about accessibility. And so this is where you start. Why? Because it’s the right thing to do!

Implementing accessibility as you go is a reality, but to be really successful in the long-term, keep seeking out accessible solutions that don’t need the extra hand once they’re built and live. Don’t let the responsibility fall on to only one person (or one small group)—Involve all team members in this process. Everyone creating products contributes to accessibility. Use the power, skills and knowledge of your team to identify possible barriers and rectify them, building those insights into accessible pattern libraries.

What have some of your aha moments been while creating or designing lasting accessible solutions that work for everyone? Share in the comments below.

2 thoughts on “Why “managing accessibility” doesn’t work (and how to do better)”

Read comments

  1. Really good article. This is something we have tried to implement in our own work but knowing how is sometimes the biggest hurdle.
    The illustration shows a perfect example of how people think and it needs to change. I totally agree that something should be built once and built well for all. One solution for everyone.
    Is there something like the google speed test that will give you a report of things to fix? Once the website failings have been addressed in this way developers would know what to address from the beginning of thier next project.

Hi there! We've closed the comments after a week of spirited discussion on this post. If there's something we've missed, please reach out and let us know.