Inclusive design: a Practical point of view
by Matt May
Happy December! Practical Equity and Inclusion earned its first ever income over the last week. More on that, with mentoring session links, at the bottom.
But first, I wrote last week about accessibility from Practical’s perspective, which leads into this week’s topic: inclusive design.
From accessibility to inclusive design
I met Jutta Treviranus, founder of the Inclusive Design Research Centre, in June 2002. We worked together (as in, I worked for her) on the Authoring Tool Accessibility Guidelines (ATAG) 2.0, which became a W3C Recommendation in 2015—some ten years after I’d left. WAI’s strategy for expanding the scope was to take the success of the Web Content Accessibility Guidelines (WCAG) and make complementary standards for browsers (or “user agents,” in W3C parlance) and authoring tools. I got to see this standard take shape from two places: first, as the person charged with making the standard happen, and later, at Adobe, as the person charged with applying it to some honest-to-goodness authoring tools.
It was… not great. ATAG suffered what I would call a bad product-market fit. The standards-editor wing of the project wanted to cover all the ways in which we know content becomes inaccessible according to WCAG. The authoring-tools vendor side wanted to know how they were going to tell regulators why they thought 75% of the standard didn’t apply to them for one reason or another.
It’s an awkward feeling to look at a standard you helped create, and feel like it didn’t help things very much. And that called into question a lot of what I was doing at work. Reporting on accessibility bugs and connecting them to WCAG helped, but created a game of whack-a-mole with the engineering teams. If there was a bug and we didn’t find it, or convince the product team it was necessary for conformance purposes, it got harder and harder to dislodge. Teams were doing accessibility work, but they weren’t reasoning their way through it, and it wasn’t sticking as part of their jobs. They did enough to pass the test, moved on, promptly forgot anything they had learned about the problem set, and made the same mistakes again.
There was one area of my work that showed promise, and that was training. I built dozens of hours of instruction for our engineers, testers, product managers, and so on to learn about core concepts of not just quantitative accessibility, as I laid out last week, but how disabled people used assistive technologies and product features to suit their needs and wants. Hundreds of employees across roles got a deeper understanding of what the standards were actually intending for them to do, and I started to get fewer questions of the “just tell us what we have to do” genre, and more that showed they were applying what they knew to the thing they were trying to build.
With that knowledge in hand, I asked to meet with Jamie Myrold, then the VP of Adobe Design. I told her about all the training programs I’d been building, and that I wanted to do something for product designers. About halfway through our talk, she asked me why I wasn’t working for her. We worked out a trial project where I presented a full-day session to her leadership at the San Francisco Lighthouse for the Blind. Then I took a long break from work, and when I came back, in December 2017, I joined her team as head of inclusive design.
My role as a product manager in Design began to decouple from accessibility almost immediately. I had been so accustomed to testing final products for technical accessibility that it took a while to realize that most of what Design was working on was theoretical. They were just mockups of a user experience that had yet to be coded. So what good was a standard that was fixated mostly on coding issues that a designer would never encounter?
I had built largely overlapping training programs for engineers and testers, but they were almost worthless to designers. I had to write something completely new for them: a program that addressed how people are excluded from our products from a theoretical and—product placement!—a practical perspective.
We adopted the Inclusive Design Institute’s definition of inclusive design, which is “design that is inclusive of the full range of human diversity with respect to ability, language, culture, gender, age and other forms of human difference.” Not being a part of the accessibility team gave me the ability to advocate for issues of exclusion not strictly along lines of disability. We dealt with issues ranging from how (or whether) to ask for a user’s gender, to respecting a range of religious and cultural practices and observations in iconography, to avoiding the use of slurs in stock photography tags, to protecting against harassment in user chats.
As Joy Buolamwini describes in Unmasking AI, a computer-vision app of her own creation used a common library for facial recognition that failed to find her, while her lighter-skinned colleagues were recognized with ease. She resorted to using a white mask to complete the project. You won’t find that kind of failure in WCAG, but it’s as imperative to fix—or, more proactively, to avoid—as anything you’ll find in an accessibility standard.
If your team is responsible for fixing this kind of deficit, how you respond may depend on whether you consider it a technical issue, or a societal one. If this were merely a bug assigned to a computer-vision engineer, they might only dig deeply enough to learn that darker-skinned faces are historically captured poorly with camera technology, and require additional processing to bring out their features and contours with similar fidelity to lighter-skinned faces.
A designer tasked with the user experience behind that same algorithm needs to understand the root cause of that deficiency in camera technology is racism. The problem is not as simple to solve as some lighting magic: its roots go back to the chemistry of film itself, and the prioritization of visual fidelity to white people’s faces. To teach that to a designer is to demonstrate that their responsibility as designers is not merely to the product team, but to the universe of people who want to use the product they’re designing. It’s also a lesson that systems are complex. They have soaked up the biases of generations of, let’s be honest, some pretty bigoted people.
In the technology of today, we are handed a Gordian knot of social ills. No checklist will undo it for us. As Antionette Carroll says, “Like all systems, systems of oppression, inequality, and inequity are by design. Therefore, they can be redesigned.” These are design problems. Designers must be empowered not just to create more inclusive one-offs built in this swamp of biased design history, but to deconstruct what’s broken and build it once again, this time on solid ground.
If you want a more accessible world, you will not get there with an engineering mindset. I think every disability advocate should also be an advocate for inclusive design. To do that, we need to do more to be literate about exclusion and bias not just for disabled people, but across the board: race, gender, sexuality, nationality, religion, age, language, literacy, locality, culture, economic status, education, connectivity. (For starters.)
You can be an expert in your own lived experience along these lines, but inclusive design as a practice requires you to be a good listener, rather than an Expert on All Humans. Research and collaboration is inherent in this work. In other words: inclusive design is a thing you do, not an artifact you produce.
One of the first things I did as head of inclusive design was to get the consent of the design leadership to let me give an in-person inclusive design workshop to every designer—over 300 of them, spread across three continents. I worked with a team of inclusion experts to help produce the materials, and delivered it in person around the world. (My last workshop was at home, in Seattle, on the day the first COVID-19 cases were identified in the US.) The next few years were a blur. With COVID, the workshops morphed into an online-only offering that made up about a third of Design’s new-hire orientation.
To compare before and after, I learned that, as with the earlier training programs, contextualizing the problem space to the work one does led to much better questions, which led to much deeper investigation. I found that designers and design researchers were the ones reasoning out how to make these complex systems work, and exposing that work as what we do here empowered designers to agitate for change in a number of areas—not all of which would I have caught as a single practitioner. I can assure you that we didn’t win every battle. But we did spread that responsibility around, and not only was it taken seriously, it made many people more engaged and passionate about the work they were doing.
Who would suspect that simply advocating for inclusion isn’t the end of the story? Next week, I’ll explain how the inclusive design practice shifted to a focus on equity.
To read
Adobe released the Inclusive Design Workshop publicly in 2020. The modules and exercises are all available under a Creative Commons Attribution 4.0 license, so you can use and adapt that content freely. If you happen to be looking for a workshop facilitator, I’ve done it more than a few times. Reach out by email and I’ll fill in the details.
Mentoring updates
As I mentioned in my last issue, I have opened up my calendar to 50-minute mentoring sessions for the first time. So far, so good! I’ve already got my first repeat client. Another mentioned that they didn’t even know this was a service anyone provided. And as far as I know, a couple weeks ago, it wasn’t! I’m looking at ways to get the word out to people who I know are doing hard and often underappreciated work that they can talk with someone who’s been through a lot of the same situations they’re experiencing in their careers. Here are the links for booking your own session:
Book a mentoring session (paid) (Monday-Friday, up to 60 days in advance)
Book a mentoring session (free) (Thursdays, up to 10 days in advance)
If your organization offers a professional development benefit that can be used for mentoring or coaching, let me know and I’ll provide you with any documentation you need.
I’m keeping the 50-minute format and the buy-one-give-one model through January, before I consider adjusting pricing, availability, packages, and so on. I’ll keep the form open through the holidays, though I’ll be spending more time offline through December. The mentoring sessions themselves don’t feel like work to me, but the other parts of running a business certainly do, so I’m going to use my unbooked time to have some fun.
Next week’s issue will most likely be my last of the year. Did I write enough in the last two months to make a best-of compilation? Let me know if you found something particularly worth sharing. Have a great week.