Shifting the mindset on accessibility in design

In the software industry, much of the discussion around accessibility is around compliance and cost. When we talk cost, we’re referring to the actual dollars we’re losing or the cost of fixing the accessibility defects. It’s not the cost to those affected by our software’s inability to work for them. It’s the resourcing and tooling costs of actually meeting the requirements in section 508 or the cost of losing a government deal as a result of accessibility shortcomings.

Over the last few months, I’ve been spending a significant amount of time thinking about accessibility and inclusive design. Behind the scenes, the advocacy of the Clarity team, especially Scott, influenced my thinking on why we need to keep accessibility as a top level item in our values, our thinking, and how we execute.

Over the past few weeks, we funded and built a dedicated accessibility team led by Sheri Byrne-Haber, an incredibly talented industry leader. We built it within the VMware Design team with the sole focus on bringing accessibility into design and development at VMware.
A big part of the shift in my thinking has been around why we need our user experience to be accessible.

My disability exists not because I use a wheelchair, but because the broader environment isn't accessible. - Stella Young

As I spent more time researching and talking about accessibility and as my mindset shifted around why we need to be thinking more about it, I am convinced that a shift in the mindset, especially for designers, is needed. The shift we need to make happen isn’t just about educating designers and engineers on accessibility, it’s about changing how they think about the concept itself.

I want to be clear that I am not the first to advocate for this. If anything, I should’ve done so earlier. Many, including on my team, have been advocating publicly for this mindset shift for years and they deserve all of the credit for what they’ve taught me over the past few months and years.

Mind shift #1: accessibility is about building for all users, not specifically building for the disabled ones

Building accessible products and services isn’t about retrofitting existing experiences for disabled users. It’s about building for all users.

Think about this for a second. Most of the time, when we talk about accessibility, we’re immediately thinking of the challenges we need to overcome and the changes we need to make in order to support accessibility requirements. This means we’re thinking of the additional work we need to do to support a few users who need accessibility features.

There are multiple issues with this. For one, it builds a mindset in engineering and design teams that assumes our default set of users does not include anybody with a disability, temporary or permanent. It assumes that users who might need accessibility features are disabled people that are costing us more money, more time, and more effort. It assumes that we build, test, and then fail because of a subset of users who need more not because of our own shortcoming in building a solution that helps all of our users achieve their goals.

Accessibility isn’t about doing the minimum required by the government to sell your software. It’s about building for all users. It’s about ensuring our software enables our customers to be more effective. It’s about ensuring what we build is empowering all of us to do their best work.

Building inaccessible software is like putting a wall in front of a specific set of users. Some of these users will be able to climb it and move on, others won’t. It’s not their disability that is preventing them from achieving more, it’s the environment you’ve built around them.

Mind shift #2: many people have a disability, at some point

Over the last few years, Microsoft has done a great job outlining some of the principles around inclusive design that focused on changing the mindset around what a disability even is.

When you think of a disability, you’re generally thinking of a wheelchair. At least I do. A part of this is the “accessibility logo” you see everywhere in real life. Although someone with a wheelchair might require different accommodations, especially in the real physical world, disabilities come in many different forms. Some are permanent, but others are temporary.  Some are visible, most are not.

For example, think of mouse usage on a computer. When we think about keyboard navigation, we think about common permanent disabilities that might prevent a user from actively using their keyboard. In reality, however, there are many temporary disabilities that might prevent a user from doing the same. It might be a father who is holding his daughter as he works on his computer. It could be a nurse at a hospital who’s holding her phone as she takes information from a patient. Accessibility is about understanding the environment, as much as it is about understanding the user.

When we think of accessibility, we should make sure we have the right mindset as to who we’re thinking about to expand our horizons to the reality of our users and the possibilities we can offer them.  Giving your design personas disabilities and understanding how they are adversely impacted and under what conditions helps establish that point of view.

Mind shift #3: accessibility pushes us to build better software

If you’ve used a ramp curb-cut before, you’ll realize that most who use a curb ramp are not disabled. Not by the definition I used to think about. You’ll see parents pushing a stroller, a man with temporary crutches, elderly citizens that prefer it to a step, a bike that’s trying to cross a busy street. All of these use cases were technically secondary to the main one, which was wheelchair users. Building curb-cuts has benefited a far larger subsection of society than what we think about when we think of accessibility.  So much so that “curb-cut” is now the industry term for something that intended to benefit one population, but ended up benefitting many more people than just in the intended group.

Building accessible software pushes us to truly think of the environment surrounding our users in a way that we might not usually do. It pushes us to think of edge cases, error conditions, and failure scenarios that we might not have thought about.

Building with accessibility in mind allows us to offer better choices for our customers. Even for those who do not need these features and abilities but they actually do want them.

Mind shift #4: accessibility is a collective social responsibility

Finally, accessibility is about doing the right thing. Companies, especially in tech, are more aware of their social responsibility today than ever before. Inclusiveness is a big part of the culture at VMware. As I think of inclusiveness, I cannot stop thinking of the importance of being inclusive of all of our customers. Diversity and inclusion, to me, is about building diverse and inclusive teams that are able to build great software for a set of diverse customers.

If your company talks about diversity and inclusion and does not have an accessibility mindset, it’s you who can bring that to the conversation!

If you found this useful, you can follow me on Twitter here where I continue to share my journey as I lead design at VMware.