Context:
What follows are my slides and speaker notes from a presentation I gave at Atlassian's internal design conference in March 2018.
I leveraged our design culture's love of memes and dry humor to:
1. help keep attendees engaged in what can often be a dry topic, and
2. soften what can sometimes feel like a guilt or shaming pitch,
which often makes engagement in the topic difficult.
To my happy surprise, this talk not only got the laughs I was hoping for, but I found that attendees stayed both engaged in the topic and processed the information and lessons, repeating them back to me with related examples in the days following the talk. Months later, I'm still pinged by attendees with questions and observations on the topic—yay! :)
Whenever we talk about the subject of accessibility, there are always a few elephants in the room. So before I start the main topic, let’s level set on those first.
It should be obvious to all that building for accessibility is the right thing to do. So I’m not going to lecture you about how…
...this conference theme is openness, we value inclusion and empower all types of teams...
...two important Atlassian values are "Build with Heart & Balance" and "Don't F&%# the Customer..."
...the tools we make decide who gets to be included in work...
...and that by making our products accessible or not, we have an effect on who doesn’t get to participate in team work
That should be a duh.
And I do think we all care.
But for the sake of argument let’s be good capitalists and pretend that money is what matters to us.
We all already work a lot. There's a lot of stuff to do. And we do a lot of stuff. All that stuff has to get prioritized into stuff we need to do now and stuff we’ll do later.
Understandably, most teams and their leads do some simple math that looks something like this…
If this circle is our pool of users, accessibility is going to solve roughly this many users’ problems within that circle (small number of people).
Designing for accessibility, conversely, especially retrofitting, sounds like giant amount of time, resources, and effort (very big scary circle).
So it’s not great, but you can see how things happen next, and priority-wise, it falls to the wayside.
I would argue, however, this way of thinking leaves us vulnerable to two key missed opportunities…
One: What I’m going to call the "Team Dinner Effect."
When I go out to eat in a large group of my colleagues, there are a handful of us out of 25 or so that have dietary restrictions.
I have an auto-immune disease called Celiac. It affects 1% of the population and means that I can’t eat what most people would consider the foundation of life, bread. I also have colleagues who are vegan, vegetarian, and pescatarian.
So of the group of 30 eaters, 5 of us have special needs Do the five of us go off and have our own dinner?
No, we want to eat as a team, so the restaurant that gets our business for 30 people is the restaurant with a flexible enough menu to accommodate those 5 of us.
You guys are all pretty smart, so I think it’s pretty easy from there to draw the parallel to how this applies to providers of software to teams (ahem, us). In particular, we miss out on the business of organizations that are most legally bound to be equal opportunity employers and service providers, mostly government and public educational institutions.
By the way, shout out, I know there are some folks on the server team already making this case for their products for Fiscal Year 19, so…yay!
But I’m pretty sure that the reason we’re really in our jobs as designers isn’t so much money, but more about the good stuff...
Designers are mostly motivated by making cool things. And since I’m talking to designers, the subject of this talk is mostly about opportunity number two: innovation.
This talk is about universal and accessible design and how it naturally pushes breakthroughs and innovations.
By designing for accessibility, we may *think* we’re just designing for that small circle of people, but the thing we’re doing at the foundation is opening up more ways for everyone in more contexts to access the functionality of what we’re making.
Most of the time when we think about the word accessibility, we actually think about people with disabilities.
But if we break down the word "accessibility" it’s really about making things accessible.
We’re opening up more angles to access the information and functionality of what we’re making. This is why some people prefer to use the word "universal design" over "accessible design."
Let’s kick this idea off with a story we can all relate to. How many of you use some kind of keyboard every day?
All the 80s children know that evolved from this, the typewriter.
Before the typewriter, though, if we wanted to write to each other, we had to do this - hand writing.
Well there was this guy — an inventor/designer/innovator Pellogrino Turri, who had an accessibility problem to solve.
He had a friend. Or “friend” depending on which 18-aughts gossip you follow. His friend was a woman he very much adored and he wanted her to be able to write him letters, but she was blind, and writing letters by hand required seeing.
So, being that he was an inventor, or designer of sorts, he created a device that allows you to print letters by pressing buttons. Once you learned where the letters were, you could touch the buttons instead of using sight to write them.
...which turned out to be totally not that big of a deal because it’s only helpful for the, like, 2% of people who are legally blind, right?
Sike. it turns out that making things easier for a blind woman made things easier for everyone, plus it enabled a lot of stuff that came after it.
The irony of this last image of a mobile keyboard is that it’s a keyboard, but, full circle, one needs sight to operate it. Maybe there’s an innovation there like using haptics to give physical feedback that helps users find the edges of the keys?
Ok, so yeah, cool story, but it's not just an anecdote.
Breakthroughs we make for accessibility tend to be breakthroughs for everyone because at their core, those breakthroughs are about opening up access and context.
Turri’s motivation may have been writing letters to his friend, but, at the foundation, what he did was create a new mode of access to written communication for everyone.
When we design specifically for accessibility guidelines, we tend to break our audience into these groups, roughly categorized by the mode by which they can or cannot access what we make.
So if we start out with our group of blind users, we see define a blind user as someone who can’t do anything that requires looking at a screen.
Other people who can't look at screens include...
Here are some examples of things that have been made for not looking at screens that might help people in those contexts...
I can have driving directions read to me so I don’t have to look away from the road.
While driving, I can voice text a friend to politely ask them to drive themselves.
I can listen to audio content via podcasts on my commute to work.
I can set the haptics on my phone and watch to vibrate when specific important people call.
I can operate functions on a phone using the physical buttons on the side I can feel while it’s still in my pocket.
And of course there’s the keyboard.
Turns out many of these contexts have ways of accessing functionality and content outside of looking at a screen.
These ones haven’t so much been solved, but hey, innovation opportunity!
Let’s unpack motor disabilities. Someone with a motor disability can’t use their hands to operate a device and/or can’t move with precision.
Other people who can't use their hands to operate a device and/or can't operate it with precision inclue folks who are:
As you listened to that list, autocomplete may have come to mind as something that’s made access easier for those limited mobility contexts.
If you Google how and when autocomplete was invented you might conclude that autocomplete was invented by Google around 2004.
But if you were to do a bit of research and watch the movie Theory of Everything, you’ll notice that Stephen Hawking had autocomplete wayyy before the rest of us. Pretty sure this was before 1990 judging by that powder blue track jacket.
Ok, if you do some actual research, you come up with a year around 1985.
Turns out we decided this guy, who had some major challenges with both movement and speech, was pretty important. So some people, including Intel, wanted to help create access for him to do those things.
The innovations for that access helped not only other disabled folks, but contributed tech foundations that now allow the rest of us to text our friends faster, and get mad when we start a search string that doesn’t complete itself after we’ve typed half of it.
P.S. RIP you wonderful human being, Stephen Hawking
And p.s., jokes aside, thanks to Google for making auto-complete ubiquitous to our Web and app interaction experiences.
More companies than Google are taking advantage of accessibility’s tendency to push innovation, though.
Some of you lucky or unlucky ones may have smashed your iPhone phone screen and, if you don’t have insurance, out of desperation found you can actually access a lot of the functionality of the phone by taking advantage of the fairly robust accessibility features. This kind of thing definitely helps the rep of Apple product design too.
This is an article from lifehacker that describes some ways to use iPhone accessibility features to make your life better, physically disabled or not. Turns out people who are blind have been getting the news read to them by robots for decades before Alexa!
For all the unsexiness that Microsoft usually embodies for designers, they have actually published an inclusive design framework with guidelines, examples, and activities that I would argue ought to be as exciting to the design community as Google Material design was.
Things are getting better for all of us as things improve for accessibility.
As companies like Microsoft, Google, and Apple make their experiences more accessible, building foundations of better experience for all their users, expectations for how we’re able to use our devices and products is elevating.
The old way:
I need to…
The new way:
I have…
All these talks are about openness and inclusion, but in this new framework, we don’t need to actually talk to disabled users, right?
Wrong.
Just like when you visit Sydney or San Francisco or Gdansk or Manila or…(all the places that Trello people live), you ask an Atlassian colleague who lives there what are the tips and tricks of being there (i.e. best food and places to play and stay).
People who live with not being able to see or move precisely or hear or speak already have some pretty good ideas about the most efficient and reliable ways to solve challenges of access. We should be working together closely on these tech solutions.
So, assuming I’ve totally convinced you that this is a worthwhile thing to invest energy into, there are few things you can do to start on this now…
One: Next time you’re solving a design problem, take a look at this list of disabilities or blockers to access and ask yourself what other ways could content be accessed?
What are some ways, for example, I might be able to get caught up on Jira on my morning commute when I’m not looking directly at a screen?
Two: In the spirit of progress over perfection, on a recent shipit, Anthony Nomorosa and I *started* a training portal to collect materials to increase exposure and understanding of how disabled users access digital experiences. Keep an eye out for a beta release and blog post.
Three: And then finally, full circle, we need to include disabled users into our design problem space just like we invite other users to chat with us and tell us about their experiences with our products.
Thank you!
Made with Keynote Extractor.