Accessible Accessibility: How You Can Help Create More Inclusive Products & Experiences

December 6, 2018

I was invited to present in Ljubjana, Slovenia, on the topic of creating more accessible products and experiences. These are the slides with my transcript of the talk.


Slide 1

Hello everyone! I’m really glad to have the chance to speak with you today.

Slide 2

Just before we kick this off, I’d like to invite you to share any questions that you might have during the talk on slido. You can do this by going to the URL you see on the bottom left of the screen, www.sli.do, and entering the event code “accessible.” If you visit that URL, you’ll also be able to see what questions other people have asked, and vote on any that you’re also interested in discussing.

The URL and event code will be shown on every slide as we go, so don’t worry too much about trying to memorize this or getting it set up right now.

Slide 3

So! My name is Quinn, and I’m a Senior UX Designer at Marley Spoon, and a partner with Caribou, a UX consultancy.

Slide 4

I’m particularly thrilled to be here today, as the last year has been a very interesting one for me. I’ve come a long way from my hometown of Winnipeg, a city right in the middle of Canada

Slide 5

known for very cold winters and for sharing a province with some spectacular wildlife.

Slide 6

Earlier this year, I made the move from Winnipeg to Berlin to join up with the Marley Spoon team.

Slide 7

I’ve had an interesting career so far. I’ve been in the industry for more than 9 years. My education was in graphic design, along with a hearty dose of self-taught frontend and backend development exploration. This combination helped me enter the industry as a graphic designer with a branding and advertising agency in Winnipeg, where I spent a few years working on all kinds of print and digital projects, both as a designer and as a developer.

After that, I moved to a role leading UX research and design at a major non-profit organization that works across Canada to conserve wetlands and wildlife habitat. Ducks, not polar bears. At the same time, I co-founded Caribou, my UX consultancy, which gave me the chance to work with all kinds of startups and organizations across the country.

When I got started in design, the topic of accessibility was almost entirely absent from our education and conversations. We might have touched upon it in passing while discussing themes like type size in printed materials, but it was only ever explored in an offhand way. The projects I was working on—things like websites for museums, banks, and zoos—were definitely used by people with a broad range of individual accessibility needs, but actually designing and implementing accessible platforms and experiences was the last thing on anyone’s mind.

Slide 8

Today, the topic of accessibility and inclusive design is a growing topic in our community.

I find this incredibly exciting. The topic of accessibility is a very personal one to me, and I have a unique and personal perspective on the impact that it can have on day-to-day life,

Slide 9

because I have profound hearing loss. Or, as I usually like to call it,

Slide 10

I’m “deaf as a post.”

I’ve heard that this one of those phrases that isn’t really common here in Europe, so in other words, my hearing is really, really bad.

I’d like to share a bit of context with you. My hearing loss is a bit weird. When I was younger, my hearing wasn’t all that bad. I got hearing aids when I was only a couple of years old, but I could still hear and understand people, which helped me learn to lip read quite well. Over time, though, my hearing got worse and worse. Today, I can still hear sound fairly well while wearing hearing aids: I can hear you cough at the back of the room, I can hear your voice in a conversation and recognize who’s talking, and I can even tell when you’re asking me a question just by the rise and fall of your pitch.

Slide 11

However, “hearing” is more than just volume. There’s a specific aspect of hearing called “clarity.” It’s the part that takes the sound you’re hearing, interprets it, and draws out specific words.

Slide 12

My clarity is totally shot. While I can hear your voice just fine, I can’t turn it into distinct words that I can understand. Because of that, I rely entirely on lip reading for conversations today.

Slide 13

It also means that I can’t use things like phones, because while I can hear you talking on the other end of the line, I can’t turn the sounds of you talking into words that I can understand.

It also makes it difficult to hold things like Skype calls, or to understand someone who’s talking at a whiteboard while they’re writing, or even to follow spoken questions at the end of talks like this one. That’s why I’ve asked you to use Slido to share your questions: it helps us bridge the gap between you and my hearing.

Slide 14

Having hearing like mine means that I run into a lot of what I call failures of accessibility. Take, for example, what happened

Slide 15

when the transit authority in my hometown introduced a new bus pass system called “Peggo.”

Slide 16

Rather than selling paper tickets and passes, they designed and introduced a new reloadable plastic card that would hold your digital tickets or passes. This isn’t revolutionary, of course, but it was new to Winnipeg and they were very excited about the system.

Slide 17

When Peggo was first rolled out, the only form of feedback that it would provide to a bus rider about whether or not their pass had been read and validated was a high-pitched beep.

When this was combined with a slow and unpredictable response time, it meant that I would get on the bus, hold up my pass, and have absolutely no idea whether or not it had been accepted.

I had to watch the bus driver’s body language and guess whether I’d waited long enough for the system to have read my card.

Obviously, this meant that sometimes I’d guess wrong. But, I’d only realize it once I’d walked halfway onto the bus before noticing that all the other passengers were staring at me as the bus driver shouted at me from the front of the bus.

Slide 18

I’d have to backtrack, embarrassed, to try again.

Slide 19

I’m not alone in experiencing these failures of accessibility. The numbers around disabilities are startling.

Slide 20

Here in Europe, almost one in five people is living with a disability. That’s 70 million individuals who may be experiencing stories like mine every day.1

But here’s the thing. I strongly believe that most failures in accessibility aren’t the result of any conscious decision. People don’t wake up in the morning and think,

Slide 21

“I know! We’ll make it shitty and inaccessible!”

Slide 22

Failures in accessibility are usually just the result of mistakes or a lack of awareness.

Slide 23

It’s not that we don’t think about it: it’s that we often don’t think to think about it.

Early in my career, I heard a story that stuck with me, involving a man named Michael Graves. Graves was an American architect and product designer that became paralyzed from the waist down in 2003, as a result of a spinal cord infection.

Slide 24

When he was dealing with this infection, he was bouncing between hospitals. On his first day using a wheelchair in his hospital room, he thought, “Oh, good! Today I can finally shave.”

So he went into the bathroom with his razor, reached for the hot water tap, and realized he couldn’t reach it. His next thought was to have someone bring him his electric razor: he could just plug it in and have at it. So he looked around for the outlet where he could plug it in, and realized it was on the wall next to the floor. If he plugged it in, he wouldn’t be able to see his own face in the mirror up on the wall while he shaved.

He called in a doctor, and said—I’m paraphrasing here—“Look at this! We’re here in the most advanced, most expensive medical facilities, and I can’t even shave my face!”2

Slide 25

Inspired by his experience, Graves became an internationally recognized advocate for accessible design.

This story struck me. Here’s an architect—someone who’s responsible for knowing and adhering to building codes that call for equal access for all. And yet, it wasn’t until he personally experienced this massive life event that he truly realized the extent to which our designed world can present barriers to people with disabilities.

Slide 26

Today, it’s getting easier and easier to hear and see the stories of those who benefit from accessibility. We don’t have to experience it first-hand, like Michael Graves, to see and recognize the need for accessibility. We can open Twitter, send an email to someone we’d like to learn more from, or go to talks like this one.\

Slide 27

We’re experiencing a cultural shift in our community. People who craft products and experiences, no matter what their role may be, are recognizing that people aren’t “edge cases.” In fact, we’re beginning to take a stand against the very idea, because it only serves to further marginalize people who are already on the margins.3

Slide 28

Instead, our community is beginning to recognize that there’s a spectrum of ability that isn’t limited to those with permanent physical or mental circumstances. Rather, people can have permanent, temporary, or situational needs and abilities, which can change depending on individual context and goals at any given moment in time.

Slide 29

Microsoft’s inclusive design toolkit4 gives us some wonderful examples. Someone might not be able to interact with a touch device with two hands due to only having one arm. But they may also have an arm injury, or even be a new parent. That means that designing a product to be accessible for someone who has one arm, actually impacts a far, far greater range of individuals that are using your product.

Vision is just another example. Making your product accessible for someone who is blind will also benefit a larger population that has a temporary condition, such as cataracts, or even situational influences, such as a distracted driver.

Slide 30

Every action you take to make a product or experience more accessible for those at the extreme ends of the spectrum will have incredible ripple effects

Slide 31

to a larger audience

Slide 32

that will also benefit.

Slide 33

Not only that, but our community has access to new and existing tools, platforms, and technology that makes it easier, faster, and cheaper to deliver accessible experiences—particularly in the digital arena.

Slide 34

Today, it’s easier to make the business case for accessibility. Chances are, many of you in this room today don’t need any convincing that accessibility is worth the while.

Slide 35

And yet, accessibility is a very large and wide-ranging topic. There are just so many things to do and know. There’s so many different situations, tools, and instructions. It can be overwhelming.

Slide 36

Accessibility often feels out of reach on a personal, individual level. How can one person, how can you specifically, make a difference in your work, when you’re being pulled in all kinds of different directions, when you’re dealing with deadlines and deliverables, or when you’re facing a workplace culture that’s focused on numbers and profits over people and experience?

Slide 37

I’d like to talk to you today about accessible accessibility. How you can make an impact as an individual, and help make more accessible products and experiences, no matter what your specific role or job title may be. Whether you’re a designer, a developer, a product manager, a copywriter, or a CTO, you can make a difference.

Slide 38

If most failures in accessibility are the result of simply not thinking to think about it, then the trick is to have a starting point for when and what to think about.

Slide 39

I believe that there are four key areas where anyone can have an impact. This isn’t some new unifying Twitter-worthy framework or anything of the sort. They also don’t fit neatly into a single discipline or methodology. Rather, they’re broad areas where I’ve noticed that it’s easy for anyone to do small things that have a real impact on accessibility outcomes.

First, we have implementation: the actual crafting of the products and experiences, taking it from design and launching it out into the world.

Second, we have design: both the process and the outcomes that result.

Third, we have processes and flows: the ways that people move through our products and experiences to get things done.

Finally, we have the workplace: the culture that we shape inside our teams and companies that can support and lift our efforts to create accessible products and experiences.

Slide 40

I’m going to go through each of these one by one. Let’s start by looking at implementation, which is rooted in how we build and deliver our products and experiences.

Slide 41

When I was younger, I was absolutely ecstatic to play the game “Quake 4.”5 My friends were raving about it, I’d heard great things, and I was looking forward to giving it a shot.

I still have no idea if Quake 4 lived up to the hype, because I only made it ten minutes into the game. It used in-game dialogue to present instructions to the player, and it didn’t have subtitles.

I started playing and had absolutely no idea what I was supposed to do, and ultimately had to give up. It left me feeling alienated and rejected—and worse, I’d spent money to have that experience.

That was however many years ago, and yet even today, this same issue is popping up again.

Slide 42

A new release called Spyro: Reignited Trilogy just came out, which is a remake of a series of older games much-loved by its audience. Unfortunately, it seems that the game was released without subtitles, and the decision kicked off some serious backlash online.6

The publisher, Toys for Bob, eventually had to publish a response to the criticism. They said that ultimately it was a business decision,

Slide 43

and that “there’s no industry standard for subtitles.”7

Slide 44

That’s not a very good response, because it passes the responsibility away from themselves and onto the industry as a whole. In this specific case, it doesn’t even align with reality, for two reasons: first, the games were developed using an underlying engine that has full support for subtitles built in, and second, the industry standard for subtitles in video games these days is essentially “have subtitles.”

Slide 45

But that’s what we need to recognize: most of our tools these days give us everything we need to make things accessible from the start. We don’t need to do the hard work ourselves: it’s all there and waiting for us. Accessible accessibility in implementation is just about knowing where and how to focus our attention to make the biggest impact.

Slide 46

First off, particularly if you’re involved in development itself, strive to meet the Web Content Accessibility Guidelines8, otherwise known as WCAG 2.1. Many of you will already be familiar with these, but if you aren’t, they’re essentially a comprehensive specification for how to make your products and experiences accessible to everyone, regardless of physical or mental ability.

Slide 47

I personally love having these as a resource, because they act as key performance indicators for accessibility in digital products. I’ve found that this goes a long way for building internal cases for accessibility, because businesses in general appreciate having KPIs that can be used to measure whether or not they’re achieving something. Accessibility risks seeming “fluffy”—like a concept rather than a measurable outcome—and the Web Content Accessibility Guidelines can help make it tangible.

Slide 48

One thing I’d like to note, though, is that the guidelines themselves are almost overwhelming in breadth and depth. I personally don’t know all of them, and it’s almost impossible to keep them all in mind at once. That’s why, for accessible accessibility, it’s important to know some of the basics that have the biggest impact, which aren’t necessarily tied to a specific role in the company. You don’t have to be a front-end developer to be mindful of these things.

Slide 49

Some of these are things like text-based alternatives for non-text content.

Slide 50

These are subtitles for videos, transcripts for audio files or podcasts or any other audio-only source, and descriptive text to accompany photos and images. Today, the technology we have access to makes creating and adding transcripts to media incredibly easy. Often, the reason videos don’t have subtitles is because nobody thought to go out and create them. Automated tools can even generate “close-enough” subtitles for us automatically.9

Slide 51

This is the only code sample I’m going to be showing you today. A button that looks like an X that closes a theoretical modal window for a moon rocket launcher.

Text-based alternatives also include things like labels for elements like these that don’t necessarily have descriptive text. In this case, we’re just adding a simple aria-label tag to the HTML element, and that’s all that’s needed to make it make sense to accessibility technology.

If you’re a developer, make a habit of adding these tags by default. If you’re a designer or product manager or anyone else, you can make a habit of providing the content for these tags by default. There’s a whole lot of these kinds of simple labels and tags that we can use with almost no effort—for example, matching tags for form inputs and labels for each input. I encourage you to take a look and familiarize yourself with what they are and how they work.

Slide 52

Next, it should be usable with assistive technology. That’s pretty broad, but the general idea is that different users may be using different technologies to access your product, and we can do specific things to help those technologies help the people using them.

Slide 53

One simple example of this is making sure that focus is highly visible whether using a keyboard or a mouse. When we use our mouse during the implementation or design process, it’s easy to forget to see what happens when someone’s using a keyboard.

Being usable with assistive technology also goes beyond the specific HTML and CSS tags and styling.

Slide 54

You’re probably familiar with websites that use “Read more” or “Learn more” links at the end of content thumbnail links. These links are pretty problematic for screen readers, because they have to go through content linearly while they’re reading content out loud, and it isn’t easy to simply skip forward and backward. Worse yet, screen readers will can sometimes read navigation out all at once—meaning a list of content links turns into repeated “Read more,” “Read more,” “Read more,” without any context.

Slide 55

In implementation, you can solve this by simply using descriptive links and copy to provide context and help users anticipate what will happen if they interact with an element.

Slide 56

It should also be modifiable to fit individual needs. This means that users should be able to adjust what they’re seeing and interacting with to make it work for them.

Slide 57

Kindles and eReaders are a remarkable example of how our technology can make products more accessible: my great-grandmother was a voracious reader all her life, but she developed cataracts later in her life, and was only able to read printed books with the help of magnifying glasses. eReaders let users control how text appears on the screen, which means someone with her vision can simply enlarge text until it’s readable, even if it means one or two words per page.

Of course, not all products are digital and capable of changing their appearance and functionality on the fly, which is where we need to provide alternate paths—we’ll take another look at that later.

Slide 58

While we can read and learn and internalize these guidelines to help us while we’re implementing our products, we can also use automated tools to help us validate what we build.

Slide 59

For example, Google offers a plugin for Chrome called Lighthouse.10 All you have to do is generate a report with it and it’ll give you a precise readout of how well you’re meeting standards.

Slide 60

This is a report of my own personal website, where you can see that I’ve got some things that I could improve on when it comes to accessibility.

Slide 61

I particularly love tools like this because they teach you the guidelines as you go. For example, it might flag that “Buttons do not have an accessible name,” which is good to know, but doesn’t necessarily tell you why it’s important. Lighthouse will tell you right there that screen readers without accessible names will simply be announced as “buttons,” which makes it pretty much useless.

Slide 62

Another tool is SiteImprove,11

Slide 63

which’ll show you right in your product where your issues can be found. Use these tools and they’ll help you learn how your technology can help make more accessible products from the start.

Slide 64

Now, it’s important to note that automated tools can’t catch everything. I saw another presentation by Nick Colley from Gov.UK12 that highlighted these same points, and I think they’re incredibly important. They built a terribly inaccessible website and tested it with these tools, and they were only able to catch 30% of the accessibility issues.13

Slide 65

That’s why it’s important to actually do usability testing, and test your products with real people in real life. Thinking back to accessible accessibility, though, usability testing can be prohibitively complex.

Slide 66

That’s why I encourage people to do “minimum viable usability testing” whenever they can. That’s as simple as identifying activities that exist in your products and experiences, and asking people—anyone—to carry out those activities. You’ll learn a lot along the way, particularly if you try doing these minimum viable usability testing studies using accessibility tools.

Slide 67

Here’s a challenge for you: can you use your product using only a keyboard? Sometime soon, come up with a few common activities that your users might need to do with your product, and see if you can get them done without touching your mouse or trackpad.

Slide 68

The GOV.UK team has an amazing “Accessibility Lab,” which is fully stocked with all kinds of technology that might be used to access their platforms.14 They can simply take what they’re building and try using it with that technology, and see what happens.

Slide 69

This kind of setup certainly isn’t accessible to everyone, but they’ve also shared an excellent list of assistive technology tools that you can use for testing at no cost at all.15 I’ll share a link to all of these resources at the end of this talk, so don’t worry too much about capturing it right now.

If you’re a developer, you can put these accessibility guidelines to work from day one. If you’re a designer, product manager, or anyone else who might not touch the code base, you can still use these same tools to evaluate and provide feedback around implementation.

Slide 70

Next, let’s take a look at design, one step before implementation. Everything we interact with, whether it’s a digital product, an interaction, or a physical design outcome, is designed. And that means that design is an opportunity for accessibility.

A couple of years ago, I went to Chicago for a conference. In Chicago, they have a pretty good public transit system, and a lot of signage to help you find your way around.

Slide 71

I came across this helpful street sign, indicating the direction of the red, orange, green, blue, purple, pink, and brown transit lines while out and about. On the surface, it seems pretty straightforward. But it wasn’t designed with accessibility in mind. 5% of the population has some form of colour blindness.

Slide 72

That means that for 5% of pedestrians trying to find their train, this helpful sign looks more like a collection of vaguely similar colour swatches that’s decidedly unhelpful.

Thankfully, this story has a positive ending for accessibility. A little further along,

Slide 73

I found this sign that’s designed to solve this exact problem by providing text labels along with the colours.

These kinds of failures of accessibility are, again, rarely an intentional decision. Rather, they’re the result of someone simply not thinking to think about accessibility.

Slide 74

Accessible accessibility in design means thinking about the many different types of users that may be using our products, and designing—or evaluating design—for the full spectrum of ability. Design presents an amazing opportunity to create more accessible products and experiences, because we can design deliberately and avoid the small mistakes—like relying on colour swatches for directional signage—that result in inaccessible design outcomes.

Slide 75

First, we should challenge ourselves to learn to recognize accessible (and inaccessible) design. This isn’t something we can do overnight, because it’s something we gain through cumulative experience and exploration.

Slide 76

Just like how chefs develop a sense of taste while cooking,

Slide 77

or how artists study how other masters carry out their work,

Slide 78

or even how musicians experiment with genres and going outside their comfort zone, we have to build upon our internal understanding of good design.

Slide 79

Something that looks good isn’t inherently accessible.

Slide 80

Thankfully, the Web Content Accessibility Guidelines17 also give us an amazing starting point for design. Not only do they set out criteria for accessible implementation and functionality, they specify specific requirements for visual design. As a designer, this is really wonderful, because constraints help us to be better designers by giving us boundaries to work within.

Slide 81

And, much like in implementation, they give us essentially KPIs for visual design during the design stage that we can use to measure whether or not our design outcomes are accessible.

Slide 82

Some of the most useful guidelines to pay attention to during the design process are type readability, use of colour, and target areas. I’ve found that these come up all the time, and are really easy to adjust and discuss as designers and during design review.

Slide 83

The first is type readability,

Slide 84

which is a mix of text size, colour contrast, and how the text appears on a background.

Slide 85

This is an extreme example, of course, but it applies to all text used across websites, products, and interfaces, whether related to typeface choice, colour, size, even letter spacing and capitalization.

Slide 86

Colour is an area where brand and accessibility can sometimes clash—so it’s important to get it right from the beginning. Imagine my surprise when, soon after joining Marley Spoon and performing a UX audit that considered accessibility,

Slide 87

I realized that our primary brand colour is an exact green

Slide 88

that can’t be distinguished from grey by individuals with the most common type of colour blindness! Of course, this is something we’re planning to fix. The easy rule of thumb when it comes to colour is to avoid leaning on colour alone to communicate meaning.

Slide 89

Things like using underlines for links and icons alongside success or error messages, along with clear message copy, can go a long way to better use of colour in your products.

Slide 90

Finally, we should be considering target areas, both in terms of size and intuitiveness. Too often, the target areas we design for interacting with controls are small and precise.

Slide 91

For many types of users, these are extremely difficult to interact with due to challenges with motion or vision. Simply designing and specifying larger target areas can go a long way to making more accessible products. Remember, some people have situational needs that can be met through these same changes—like when they’re using your app after being outside in the cold and their hands are all stiff.

Funny enough, even when target areas are large enough to interact with, we often run into design issues where users aren’t certain how to interact with them because they lack affordances or signals to help them out.

Slide 92

I really love looking for examples of these out in the wild, because users will often add what I call “distress signals” to products that suffer from these issues: they’re user-generated solutions to help others avoid running into an issues that must come up again and again.

Slide 93

Much like in development, there’s lots of tools out there we can use to help us evaluate our design outcomes for accessibility.

Slide 94

We can check for colour contrast ratios at different text sizes and adjust our colour choices to meet the minimums specified in the Web Content Accessibility Guidelines. We can use colour simulators to see how our designs are affected by varying colour vision.

The same browser-based tools like Lighthouse will also catch these kinds of issues after it’s been implemented, but it’s best to get it right in design, before it ever goes into development.

Slide 95

And, of course, we can test our designs with users to see if they’re able to complete the activities they want to do. Minimum viable usability testing can help here, too, by simply rigging up simple prototypes and having people try to complete activities. The more we can learn about how people use our designs before they go into development, the more effective and accessible we can make our products in design while spending less time and money fixing things after the fact.

Slide 96

Next, let’s take a look at processes and flows. Processes and flows exist within and around your products and experiences, and ultimately shape how your product works. Those processes have a big impact on accessibility, because when things go wrong, they can prevent people from getting anything done at all.

Slide 97

Back in Canada, I have a business bank account for Caribou with one of the major Canadian banks. Things were going swimmingly with them up until the day that I forgot my online banking password.

Easy! I’ll just hit “Forgot password” and get a new one sent to me, or reset it myself, just like I’d do on every other website. Unfortunately, since this was a business bank account, the bank had set things up so that I couldn’t do this online.

Slide 98

The only way to reset my password was to call the bank directly.

Which, obviously, I can’t do.

Usually when I run into situations where I have to make a phone call, I have my partner do the call on my behalf, or when necessary, we do this back-and-forth dance where she’ll listen to what the other person is saying, repeat it for me, and then I’ll reply myself. This wasn’t going to cut it for the bank, though, and they said the only option I had was to go to the bank in person.

Slide 99

When I made the trip to the bank, I explained my situation to the bank manager, thinking there’d be an easy solution. However, the manager didn’t quite get it; they suggested that I use their phone to make the call.

After realizing the issue with that suggestion, they decided to make the call themselves. Progress! The bank manager rang up the bank’s password reset team, and they absolutely refused to speak to her, because she wasn’t me.

She had to argue with them for half an hour to get my password reset.

When things go wrong within processes and flows, they create really poor experiences.

But these processes and flows don’t just happen.

Slide 100

They’re the result of a cumulation of decisions, and non-decisions. And there’s often a lot of decisions to be made, which means there’s a lot of decisions to be missed.

Part of the reason for this is because of how we work as humans: we have all kinds of cognitive shortcuts

Slide 101

that we’ve evolved to help us deal with the sheer amount of information we’re working with every day, and to make decisions based on that information without getting bogged down in analysis paralysis.18 But those same biases mean that when we’re thinking about processes and flows, we’re subject to things like

Slide 102

the primacy and recency effect, which show that we find it easier to remember things at the beginning and end of a list than the middle.19

Slide 103

When we try and keep these complicated processes straight in our heads and rebuild them in conversations, it’s easy to get fuzzy on the details, let alone think of all the ways that people may run into barriers.

Processes and flows are an amazingly accessible opportunity for better accessibility, because they tend to flow across the entire product and company, involving many different people, teams, and disciplines.

Slide 104

The easiest way to make an impact here is to get the processes and flows out of your head and onto a shared canvas. Getting people together to visualize and explore what’s going on for your users while they’re using your products is an amazing way to not only find potential moments of exclusion, but to improve collaboration between teams and disciplines in your company. When your processes and flows are out in the open, everyone can work with the same pieces.

Slide 105

There’s many ways to do this, but I’ve found the three most effective for getting it started are experience mapping, user story mapping, and user flow diagramming.

So what’s the difference between each of these?

Slide 106

Experience mapping typically averages out the experience for many users as they get things done, with a particular focus on what they’re thinking, feeling, and doing at any given moment.

Slide 107

An experience map uses columns of “steps” or “tasks” as the backbone for the map, which can then be further grouped into stages or journeys. Experience mapping is wonderful for identifying problems, pain points, and opportunities in the context of the overall experience.

Slide 108

User story mapping is a bit more detailed and focuses on the user problems over time. We often articulate features for development by creating user stories, like “As a team captain, I want to create a team.”

Slide 109

User story maps visualize all of these user problems and help us prioritize our work.

Slide 110

User flow diagramming is a closer look at the actual user interface

Slide 111

and how users move between screens, states, or features while they’re getting things done.

Anyone can plan and facilitate a workshop session and bring people together to create these kinds of visualizations.

Slide 112

The minimum viable approach is to grab a whiteboard or a bunch of sticky notes and sharpies and get started.

Artifacts can usually remain low-fidelity. I personally don’t often create polished high-fidelity versions of these, because it doesn’t always offer additional value.

Slide 113

When you aren’t able to bring in all of the stakeholders that may benefit from the outcomes of the process, though, it can be worth making high-fidelity versions of these maps. Some useful tools for that are Mural, InDesign, or even tools like Sketch and Figma.

Slide 114

The artifacts you create out of these workshops are a starting point. Use them to look for moments of exclusion within the processes and flows within your product. As you look at the steps and tasks that users move through, consider whether those steps and tasks are accessible to everyone, using the spectrum of ability as a guideline. Consider things like vision, hearing, speech, or mobility. If you realize that a step may not be accessible due to assumptions around the user’s ability, flag it as a pain point and an opportunity to create a better user experience not only for those on the far end of the spectrum of ability, but for the wider range of users that may be experiencing temporary or situational barriers. Use it as a starting point for conversation.

Slide 115

Often, you may realize there’s no simple solution within the task itself—such as phoning the bank—and you can use that as an opportunity to create and prioritize alternate paths within the existing process.

Slide 116

Finally, let’s take a look at our own workplaces. Accessible accessibility starts at home. The culture that we create and shape within our own teams and companies, or even as a consultant or freelancer working with outside teams, can support our efforts towards creating accessible products and experiences.

Slide 117

When we have a culture of inclusion within our organizations, accessibility becomes the standard. We don’t have to build a business case for it, because each of us is already looking for opportunities to build more accessible products.

Slide 118

I believe that creating a culture of inclusion in your workplace begins with making sure your own workplace is accessible and inclusive. Unfortunately, accessibility in the workplace tends to focus on the purely physical environment, while barriers are often found in the way we approach our internal processes. I’d like to give you an example.

Slide 119

For people living with hearing loss, the rise of the internet has been absolutely life-changing.

Slide 120

Suddenly, I had this new, text-based form of communication. I no longer had to rely on others to make phone calls for me. I could talk directly with my friends and family in a way that I’d never been able to do before: quickly, easily, and without mishearing or misunderstanding each other. The internet created a new bridge for human connection.

Slide 121

Hearing loss doesn’t exist on the internet.

Slide 122

Until we decide that it does. I had a conversation with someone about a position at a tech-based company, and they told me,

Slide 123

“Remote work would be impossible with a hearing problem, because we use video calls for everything.”

Slide 124

This kind of thing tends to happen when we mistake artificial barriers for hard barriers—when our approach to our own internal working processes is tied to tools, rather than outcomes.

Slide 125

Show of hands: does your company use Skype or other video calling tools for conducting job interviews with potential candidates?

I’m pretty sure that our community uses these tools more than most other industries. For those of you who had your hands up just now, I’m betting that your early emails to candidates look similar to this:

Slide 126

“I would like to invite you to the first step of the process: a Skype phone call with one of our team members.”

As a candidate with a hearing problem, this kind of message represents an awkward barrier within the interview process, because now I have to reach out and share the details around my hearing loss, and request that they provide an alternate path or solution for me. While it’s great to stand out as a candidate due to your work, your personality, or your hopes and dreams, it’s not usually ideal to stand out because you’re asking them to change how they do things.

Slide 127

Thankfully, this is an area where accessibility is accessible—in our own workplace. We can take initiative to look at our own processes and communications, and ask whether they’re focused on outcomes or tools.

Slide 128

The same email invitation for an initial interview can be transformed and made more accessible by simply rewording it to focus on the outcome: “I’d like to invite you to the first step in the process: a conversation with one of our team members. We typically use Skype, but let me know if there’s another method that would work for you.”

Slide 129

Remember, almost everything you do in your workplace is something you decided to do. It goes beyond the interview process—consider your day to day work as well. Meetings are a great example.

Slide 130

Let’s see another show of hands: have you ever missed something in a meeting because you were tired, distracted, or because the speaker mumbled or misspoke?

Slide 131

I absolutely love having access to transcripts or detailed notes of meetings. They make it so that I don’t have to worry about whether I’ve missed or misheard anything, and they help every single other person who was in the meeting, even if they don’t have hearing loss.

Slide 132

Making and advocating for these kinds of changes within your workplace can also go a long way towards creating a culture of inclusion, because it can help us become more aware of our own biases that may affect how we interact with others. Bias is an ongoing and pervasive issue within the workplace that goes beyond persons living with disabilities.

I had a conversation with someone at a prospective company a while back that highlighted this very issue. I was nailing it. I shared stories about how, as a UX designer and consultant, I’d ran meetings, held workshops involving a wide range of stakeholders, and presented challenges and opportunities to C-level executives. And then, halfway through a sentence, I was interrupted as they asked,

Slide 133

“I have a concern: how did it work until now with the hearing problem? We need to ask this, as we have many meetings and stand ups.”

Only a few moments later, while I was sharing a story about a project—one that I was very proud of, that I’d taken the reins and seen through from ideation to implementation, and had generated outstanding results against the KPIs—and talking a lot with my hands, as you’ve probably noticed—they interrupted to ask:

Slide 134

“Are you using sign language?”

Unfortunately, this interview doesn’t have a happy ending, as it was aborted out of the blue when they cut me off to say,

Slide 135

“We need to make sure that we are allowed to hire you.”

Knowing that I had a hearing problem changed how I was perceived.

Slide 136

I was no longer defined by my experience, my work, or my goals, values, or achievements.

Slide 137

I was defined by my hearing. Before I had this conversation with them, they learned about my hearing, and then the way they perceived me throughout our conversation was shaped by their own preconceptions around what it meant to have a hearing problem—at the expense of what I was actually telling them during our conversation.

Slide 138

This kind of issue is usually rooted in the same cognitive biases that we as humans evolved to help us deal with the sheer amount of information we’re dealing with on a day-to-day basis, and to help us make decisions. It isn’t an easy problem to solve. And yet, as individuals, it’s accessible to us: it’s as simple as being mindful about our own biases and the existing preconceptions, or mental models, around disabilities that influence how we perceive each other.

Slide 139

One in particular that I’d like to challenge you to consider is confirmation bias: the tendency to seek out information that supports your own beliefs, and rejecting or ignoring information that goes against it.20 Confirmation bias affects everyone. When it was originally identified and defined by the researcher Harold Kelley, he demonstrated that simply telling students that a teacher they were about to meet was “rather warm” or “rather cold” was enough to influence whether the students perceived the teacher as outgoing and friendly or cold and distant.

This same bias affects the workplace. We all have mental models around disabilities, gender, race, and much more that shapes how we perceive each other—and whether what we perceive backs up what we think we know.

Slide 140

And unfortunately, these same biases also extend beyond how we perceive each other. We often have mental models around roles and responsibilities in the workplace—what’s needed to be in, and to perform in those roles—and, unfortunately,

Slide 141

and, unfortunately, these mental models around roles and responsibilities tend to be exclusive, not inclusive.

Slide 142

That’s why a culture of inclusion gives us a starting point. It helps create an environment where we challenge ourselves, and each other,

Slide 143

to look for ways to create a team that’s built around a broad range of abilities and backgrounds. A culture of inclusion makes for diverse, stronger team with a wide range of capabilities, challenges, and experiences, which makes for a more desirable workplace.

Slide 144

And it’s a self-perpetuating cycle. Having a culture of inclusion and a diverse team within your workplace makes it easier to spot moments of exclusion in our products and experiences. That makes it easier to make the case for accessibility.

Slide 145

So, to wrap this up:

Slide 146

accessibility is a huge topic.

Slide 147

But, it’s accessible to each of us on an individual level. It doesn’t matter what your role is.

Slide 148

We looked at four broad areas—implementation, design, processes & flows, and the workplace—that weren’t tied to any specific discipline or skillset. Using these areas as a starting point, it’s possible for us

Slide 149

To do a little bit, every single day, to create more accessible products and experiences. And remember—

Slide 150

you won’t get it perfect, and that’s okay.

Slide 151

Every small thing you do will make your products and experiences more accessible not only for those who need it most, but for everyone.

Slide 152

Thank you.


Annotations, Links, and References

  1. Distability Statistics – Need for Assistance

  2. Famed architect Michael Graves, in a wheelchair, widens his design focus

  3. With thanks to Eroil Fox

  4. Microsoft Inclusive Design

  5. Quake 4 on Wikipedia

  6. "Regarding the glaring lack of subtitles in the Spyro collection - huge publisher @Activision and @ToysForBob (of Skylanders fame) are basically saying 'we evaluated whether it was worth the cost and effort to keep Deaf and HH players happy, and we decided that it wasn't'"

  7. Toys for Bob responds to Spyro subtitle criticism

  8. WCAG 2.1

  9. I recommend Otter.ai, which generates subtitles for uploaded media or in close-to-real-time. I use it in meetings every day.

  10. Lighthouse

  11. Siteimprove Accessibility Checker

  12. Nick Colley: Accessibility in the Gov.UK Design System

  13. What we found when we tested tools on the world’s least-accessible webpage

  14. Creating the UK government’s accessibility empathy lab

  15. Assistive technology tools you can test with at no cost

  16. WCAG 2.1, again

  17. WebAIM Color Contrast Checker

  18. List of cognitive biases on Wikipedia

  19. Primacy & recency effects (serial position effects) on Wikipedia

  20. Confirmation bias on Wikipedia