Is Accessibility Changing?

Accessibility has been an issue for as long as there have been people identified as having needs that are different to most people’s.

In other words, for as long as there have been people.

Because there have always been people with disabilities: impairments, genetic and acquired, that make independently carrying out easy daily life tasks difficult, and difficult things sometimes impossible.

And yet the history of humankind has been one of creating a built environment that best suits people who have no physical, sensory, intellectual, psychiatric or social disabilities.

The same is true for almost all the products we create and services we provide. Why do we do that? Why do we keep designing for the perfect human being?

The assumption seems to have continually been (and still is) that people with special needs could, should and would use some kind of assistive device. Or rely on other people to help them. Or just do without.

The brief history of the web has – despite best intentions, stated aims and ample opportunity – followed much the same pattern, except worse because we know people do have access needs and use assistive devices and we still don’t design or engineer for them.

Despite the evolution of a prodigiously detailed listing of possible web access needs and how they can be met – aka the Web Content Accessibility Guidelines – web professionals across all disciplines have continued to regard accessibility as being about edge cases, the addressing of which is hard to justify in terms of effort, cost or even good PR.

But could this be changing?

Could we who shape the web and the digital world in general lead the way in looking at accessibility in a more positive, inclusive, productive and honest way?

A way that acknowledges, includes, addresses and normalises the edge cases?

I’m seeing two indications that steer in that direction. First, I see more speakers at web tech conferences specifically addressing “difficult” disability and accessibility issues. At the recent Web Directions Code conference in Melbourne, software engineer Aimee Maree Forsstrom gave a great technical talk on Making Modern JavaScript Frameworks Accessible – something often previously regarded as just too hard.

Second, more speakers at web tech conferences on any topic seem to include references to accessibility issues as a matter of course. Rather than being an afterthought or an add-on, accessibility is becoming accepted as part of every web professional’s job, and that’s reflected in the tone and content of a lot of web tech blog posts, articles and podcasts.

Ashlea McKay slide screenshot

At the UX Australia conference in Sydney back in August, I saw a presentation by Ashlea McKay, called The autistic UXer: Designing with and for a different kind of mind.

Ashlea McKay is a UX researcher, designer and writer. She’s also autistic and didn’t find out until she was nearly 30. It turned out to be the best thing that ever happened to her.

This talk struck a lot of chords with me. When I began work at an information service for people with disabilities in the early 90s, autism wasn’t even acknowledged as a disability and there was little understanding or support until the higher functioning Asperger’s syndrome was identified as an autism spectrum disorder, and education-based support funding was made available.

And here I am at a UX conference in 2017 looking at and listening to not just a designer who understands autism, but a speaker who is autistic. Progress!

Ashlea’s positive view of her autism reminded me of the Deaf people I worked with at the Theatre of the Deaf in Sydney. They were culturally Deaf young adults who really had no interest being anything other than what they were. As with Ashlea: different, sure – but not worse, not better: different.

You can see the slides from Ashlea’s presentation here, and the audio recording will be online soon, too.

Technical Wrong book coverIt is within our capabilities to design for different, for the full range of human experience and ability, to take into account diverse needs and to not – intentionally or unintentionally – exclude anyone.
In her excellent book Technically Wrong: Sexist Apps, Biased Algorithms, and Other Threats of Toxic Tech, content strategist Sara Wachter-Boettcher relates an anecdote that goes a long way to putting the “average person versus accessibility edge case” argument into proper perspective.

In his book The End of Average, [ Todd ] Rose tells the story of Lt. Gilbert S. Daniels, an air force researcher, who, in the 1950s, was tasked with figuring out whether fighter plane cockpits weren’t sized right for the pilots using them. Daniels studied more than four thousand pilots and calculated their averages for ten physical dimensions, like shoulders, chest, waist, and hips.

Then he took that profile of the “average pilot” and compared each of his four-thousand-plus subjects to see how many of them were within the middle 30 percent of those averages for all ten dimensions. The answer was zero. Not a single one fit the mold of “average.”

So, what did the air force do? Instead of designing for the middle, it demanded that airplane manufacturers design for the extremes instead—mandating planes that fit both those at the smallest and the largest sizes along each dimension. Pretty soon, engineers found solutions to designing for these ranges, including adjustable seats, foot pedals, and helmet straps—the kinds of inexpensive features we now take for granted.

There are two key points in there. One is about designing for extremes instead of for a non-existent average. The other is that, given a set of constraints and a clear need to meet, engineers will engineer a solution that accommodates the differences within a range of extremes. That’s what engineers do.

But too often, tech doesn’t find these kinds of cheap solutions—the digital equivalents of adjustable seats—because the people behind our digital products are so sure they know what normal people are like that they’re simply not looking for them.

By the “people behind our digital products”, Sara doesn’t mean the hands-on designers and engineers – we know that designers can design for accessibility and engineers can engineer for accessibility – it’s the people who run the companies employing them that define accessibility as edge case, and sideline it.

What we need to do is what that air force did. Instead of designing for the middle (that suits no actual person), design for the extremes of human experience. That will, by definition, cover the needs of everyone between the extremes, as well. Accessibility will stop being about meeting edge case needs and about true inclusivity as a matter of course.

Sarah Pulis talk

It’s a matter of considerable excitement for me that the upcoming Web Directions Summit conference (a true coming together of designers and developers) features a presentation on this very topic, Designing for Extremes, by my friend and erstwhile colleague Sarah Pulis.

I’m sure it’s entirely deliberate that the description for Sarah’s talk doesn’t once mention the words “accessibility” or “disability”, despite Sarah being acknowledged as one of this country’s most experienced and expert practitioners of web accessibility.

I like that. It speaks to the fact that we are all users with specific needs, and none of us are average.

If enough web professionals pay serious attention to what Ashlea McKay, Sara Wachter-Boettcher, Sarah Pulis and many other informed web professionals are telling us, maybe we’ll embed accessibility techniques into our work as a matter of course in the same way we’ve embedded responsive design into our work.

Maybe – just maybe – we’ll even stop talking altogether about disability and accessibility – what sets some people apart from others – and talk just about empathy and inclusion and how the web brings us together, differences and all.

Let’s do that.

Disclosure: I currently work for both Web Directions and UX Australia conference organisers, as well as being a freelance web designer, developer and content strategist.

Leave a Comment

Your email address will not be published. Required fields are marked *