Accessibility: the developer’s overlooked responsibility

1 November 2016
| |
Reading time: 10 minutes

This is a (fictional) story of one woman’s quest to get on a train to Cardiff.

Our hero, Anne Example, is 43 and lives in a remote Welsh village. From here, she runs her business, Jams By Example Ltd., supplying home-made jam to cafés throughout the UK. Today, Anne is going to Cardiff, for a meeting at 14:00 with a representative from a large European supermarket. They want to licence Anne’s recipes and sell her innovative British jam in their stores in France. The deal could be worth millions.

Anne goes to the village railway station and buys a return ticket to Cardiff. She goes to the platform, and at 10:59, a Cardiff train rolls up to the platform.

But, Anne can’t get on it.

At this point I should mention that Anne uses a wheelchair. And at this railway station there is a large gap between the train and the platform edge.

The gap (and the lack of a level boarding ramp) means Anne can’t get her wheelchair across the gap and into the train. The gap will stop her from getting to Cardiff on time. The gap means her deal with the large supermarket will fall through.

Anne is disabled, because the train was not accessible to her. And thanks to that, she’s wasted her time, money and effort.

What is disability, really?

When we talk about accessibility (building things for use by disabled people) it’s good to take a step back here and ask a deceptively obvious question: what makes a person disabled? The definition of ‘disability’ is hotly contested amongst different communities.

Let’s look at Anne on the railway station platform again. What is it, in that instant, as she tries (and fails) to board the train, that disables Anne? There are two main ways of modelling this.

  • The traditional medical model of disability would say that Anne is disabled by the condition that stops her using her legs to step across the gap and onto the train. (This might be disease, a previous injury, or a congenital condition).
  • The more modern social model of disability would say that Anne is disabled by the gap between the train and the platform, which creates a barrier that stops her moving her wheelchair into the train.

This may seem like semantics, but it leads to a wider shift in the way we understand disability, and how to design for it.

Under the medical model, Anne’s disability is caused by her impairment (the physical difference that stops her using her legs). So, it’s logical to fix the problem at its source, with treatments that allow Anne to use her legs again.

But even if we can ‘fix’ an impairment, it might not be pleasant. What if Anne could have therapy to restore use of her legs, but it had a three month recovery period (something she, and her business, could ill afford)? If she lived in the USA and had to pay for her healthcare? What if the procedure was very painful, or carried a 0.5% risk of death? A 5% risk? 50%?

And, more importantly, what if Anne is perfectly happy living her life using a wheelchair, and doesn’t want to be ‘fixed’? And why would she need to be—other than to save the train company the cost of fitting boarding ramps?

Conversely, if we treat the ‘source’ of the disability as the gap between the train and the platform, the conversation shifts. The British disability charity Scope says:

The social model of disability says that disability is caused by the way society is organised, rather than by a person’s impairment or difference. It looks at ways of removing barriers that restrict life choices for disabled people.

The way to fix our example problem under the social model is for the train company to install a boarding ramp, or, better still, change the size of the platform to reduce or eliminate the gap between it and the train.

This means that the onus is on the train company, not Anne, to remove the barrier that stops her living her life as normal. The only thing that’s different about Anne is that she has a physical difference from what is considered ‘normal’—and because she’s different, her life choices are limited. The impairment itself only leads to disability because society fails to account for what’s different about people like Anne. There’s a word for this: discrimination.

(Re)Moving the barrier

Most developers probably know a little about the accessibility features built into most computers (screen readers for blind people, StickyKeys for people with motor impairments, etc.) Relatively few developers, however, make any real effort to make their software accessible, or to test it.

This is a shame, because there are many ‘quick wins’ that would improve the user experience for disabled people. For instance, images on web pages that don’t have alt-text (or have meaningless alt-text) are totally inaccessible to blind users. There are also a number of anti-patterns that get repeated time and time again. Images which contain important information in the text that get shared by many brands on social media? Not accessible. Images which contain nothing but text? Not accessible, and also looks ugly on high resolution displays. These all create barriers that stop people who rely on screen-readers, or automatic translation, from understanding what’s on your web page.

(A nice side effect of forcing yourself to add alt-text to all images: if you’re having trouble writing alt text for that generic stock image you’ve added to your article, maybe you don’t need the stock image at all. Can’t think of alt-text to describe your corporate brand ‘swoosh’? Maybe it should be a background-image rather than an img. Image with just text in it? Maybe you can just use the text instead, and use @font-face to make it look pretty.)

There’s valuable insight to be gained by getting disabled people to test your software and offer their feedback. For instance, some user interaction models that sighted people take for granted will make no logical sense from the point of view of many blind users.

Not an edge case

Think of the number of systems you use that use the colours red and green to denote status (success, failed, etc.) It’s an obvious choice to use red and green: they’re used in traffic lights. Red means danger, green means go.

Or does it? According to NHS England, red-green colour vision deficiency (CVD) affects around 1 in 12 men, and 1 in 200 women. There are around 31 million males in the United Kingdom, which means around 2.5 million people who experience red-green CVD. Even with a smaller incidence, 1 in 200 still makes about 160,000 women who experience red-green CVD. To all these people, red and green by itself is useless at denoting any kind of information.

It’s tempting to see impairment or disability as some kind of edge case. But 2.5 million (give or take) is a huge number. And even statistics like this don’t tell the whole story.

As time passes and we go about our lives, bits of our bodies stop working, through trauma, illness, misfortune, or wear and tear. We can’t see or hear as well as we could, we can’t walk or run as quickly, or carry loads that are as heavy, and our memory gets worse. And the reality is that as bits of us stop working, our ability to do things is compromised – people become disabled. According to the Papworth Trust, disability becomes more common as we grow older – 83% of disabled people in the UK ‘acquire’ their disability after birth, and while 6% of children and 16% of working-age adults are disabled, that rises to 45% over the state pension age.

So while it may seem that disability is an edge case, it’s one that many of us are likely to encounter at some point during our lives. Any one of us could have an accident or a disease that causes a physical impairment starting tomorrow. This is perhaps the most relatable argument for designing for disability. One day, chances are, it could be you.

Drawing the Line

A few weeks after the release of the iPhone 4, Steve Jobs called members of the press into a presentation hall and said, “there is no Antennagate!” He was referring to the fact that left-handed people had discovered, when holding their iPhones 4, that their fingers short-circuited the antenna and dropped their calls.

Mr Jobs showed videos of similar “death grips” on various Android and BlackBerry phones as counter-proof. These did exist, but they weren’t triggered by holding the phone in an ideal grip for a left-handed person.

Is left-handedness a disability? Around 10% of people are left-handed.

I was once asked for help in a library by a gentleman who was having trouble signing up for an email account. (He’d been sent to the library by the Job Centre to look for work.) He complained the form wouldn’t accept his postcode (beginning GU15) and re-typed it: G-U-I-5.

The man clearly had very little experience with computers, and didn’t know that the computer would distinguish between a capital letter I and a number 1. Did this lack of contextual knowledge disable him? In 2016, according to the Office for National Statistics, 11% of households in the UK had no internet access. Computers have only been in schools for the last twenty to thirty years.

I once knew a teacher who had a student who couldn’t read at all. He’d been put on a train to Southampton to see his father, and missed his stop because he couldn’t read the station signs, and—listening to music on the train—couldn’t hear the announcements.

Maybe the education system let this person down. Maybe he had learning difficulties. But, in any case: was this young man disabled? According to the Literacy Trust, 16% of adults in the UK are functionally illiterate and have trouble understanding unfamiliar texts. That’s 5.2 million.

Even if you want to argue about whether or not these are disabilities, they affect huge numbers of people, and these are barriers that stop them living their lives to their full potential.

Usability is accessibility, accessibility is usability

In 1995, Hillary Clinton (who was then First Lady of the USA) declared, at a UN conference, that “human rights are women’s rights and women’s rights are human rights, once and for all.”

I propose that we borrow from this when considering accessibility as a business need, when specifying, designing, and building software.

If our app uses red and green to indicate status with no alternative, it’s not usable by colourblind people. If our app relies on a user remembering their place while performing complex tasks, it’s not usable by people who experience short-term memory loss. If it has extremely low contrast ratios, then for a significant portion of the population, it’s not usable. If it uses complex and confusing language, it’s not usable by people with learning difficulties or who don’t understand English well. Not usable, and, as a result, not accessible.

We need to change the way we discuss accessibility. Disability is not an edge case, and accessibility is more than a ‘nice to have.’ As developers, we have a responsibility to ensure our software is accessible to as many people as possible.

Accessibility is part of our job, and we should be designing our apps to be accessible as standard, just as we design our apps to be usable as standard. Because in the world of software, to all intents and purposes, they are one and the same. In the words of Mrs Clinton, accessibility is usability, and usability is accessibility, once and for all.

Comments (0)


Sign up for our Updates

Sign up now for our updates.

This field is required
This field is required
This field is required

I'm interested in:

Select at least one category
You were signed up successfully.

Receive regular updates from our blog


Or would you like to discuss a potential project with us? Contact us »