Accessibility and the product person
This post is a slightly modified version of a talk I presented to the product practice at my work. It presents a few ways that product designers and managers can help to move accessibility forward. It is a little bit different than what I normally share, here, but, I thought it may be interesting to some folks.
I’m not gonna make a case for why accessibility is important; my hope is that we’re pretty well aligned around why.
Today I’m going to focus on what product folks can do to push accessibility forward.
The tl;dr of it is that we need to make accessibility a core part of our processes:
- We need to add it to our acceptance criteria and definitions of done if it isn’t there already.
- We need to have a plan for how to improve our products’ accessibility and know that compliance isn’t the goal, but the minimum. It is the floor. There is always room for growth.
- And, as we achieve accessibility, we can celebrate those successes. Sharing how we’ve done it, and why.
Many product folks have shared this meme. It is beloved in the community because it offers a concise vision of product, and tugs at some nostalgic heartstrings while doing so.
I also think that this meme offers a vainglorious view of product.
How annoying would an awesome burial form be? Or a tax form? These shouldn’t be noticed. No one should remember these forms for good or ill because these services are doing their jobs if they work and are totally frictionless.
Most of the products we work on are infrastructure that folks are obligated to interact with.
A real life example of a frustrated experience that we can see today is Namely’s PTO request form. That form takes a sighted person who can use a mouse a few seconds to complete. I urge you to try and complete that form using either a screen reader or only a keyboard. No mouse.
It is a gnarly-cumbersome experience because one of the form fields isn’t directly reachable from the keyboard.
When products aren’t accessible folks don’t have a clear way forward. So, how can we avoid confused, and frustrated Mario here?
The PTO request form on Namely isn’t empowering rad shit, as the meme says, it is frustrating and makes what ought to be a simple task a difficult one.
It makes what should be an unmemorable obligation an annoying experience.
But how do we avoid this? How can product folks help to prevent this situation?
Accessibility is often seen as a concern for UX and engineering — today I’d like to say that product folks are also key to creating accessible stuff.
My suggestion is to stop thinking about inclusion and start thinking in terms of exclusion.
By identifying points of exclusion, those moments where folks are either wholly forced out of your product, or, more likely, have to come up with homegrown workarounds to complete some task, we can start to take actionable steps towards more inclusive products!
Sometimes you may have to make the hard choice of who’s in and who’s out; I think this is the type of choice that product should make, not growth, not sales, not engineering or design. Product should make this call because product often has the longest memory — product folks can back the choice up with data and continually work towards products with fewer points of exclusion.
If someone has to be excluded at least have data about who, and immediately work on a plan for how to bring them in.
Thinking in terms of inclusion tends to lean aspirational, while by framing things in terms of those points of exclusion we can more easily come up with actionable steps to help create more inclusive products.
Again, how though? How can we identify points of exclusion…especially when we’re talking about something that hasn’t been built yet?
We start by examining the assumptions we’ve made and making sure that they are informed by research, and also informing new research.
- Are our assumptions excluding anyone?
- Are there folks who are having to work around any assumptions we’ve made?
The popularization of hashtags on twitter is an example of this, or a child climbing a counter to reach a cabinet in a kitchen.
- Twitter’s initial assumptions didn’t include groups wanting to use it as a tool for organizing, but folks worked around this hole by developing the hashtag. Twitter reacted to this, and baked support for hashtags into the platform.
- If a kid has to climb a counter to reach a cabinet, they’ve been excluded from that space, perhaps for a reason though?
What assumptions informed these choices?
Of course, the best way to interrogate your assumptions is to include disabled folks in the discussion. Folks excluded from your product and the system that produces it — that isn’t always in our power and is a bit out of bounds for this presentation, but, include and prioritize these voices whenever possible.
Next we make sure we have metrics about accessibility.
This, in my experience is the trickiest of my suggestions. A lot of things look and smell like metrics about accessibility, but end up being metrics about delivery.
To help ensure that our metrics are actually about accessibility, which is less an end-state and more a practice, or way of working, I’d suggest that we start by having metrics that focus on our teams’ processes and tracking how we approach accessibility in our day-to-day work.
Rather than track that we delivered some number of accessible components, I suggest that we track that our team has a plan for improving accessibility — like a tiny maturity model — so we can track this improvement in our processes.
For example, a metric tracking the number of components you shipped to production that include accessibility guidance.
Last but not least, don’t hold a meeting where you don’t mention accessibility, and, maybe most importantly, celebrate as you continually achieve accessibility beyond compliance.
We hear a lot about gaps in accessibility, and rarely about victories.
Because of this I think there’s an idea that accessibility is all about compliance and gloom; whereas we have an opportunity to make it about playgrounds and connection and innovation. It can be the next chapter in how we do this thing we do.
That is probably my most important point:
- Celebrate as you achieve accessibility to help show that it is doable.
Just like when “mobile-first” was the catchy rallying cry, we can celebrate and spread “accessible-first” methodologies and help to popularize it as a core principle for any new projects.
Accessibility isn’t the sole responsibility of specialists, it is a facet of the work everyone does.
Achieving accessibility beyond compliance isn’t possible through technical means alone; it also involves a certain amount of cultural change. I think cultural change is a responsibility that a product practice carries.
When folks started to embrace mobile, some businesses did quick fixes to update existing solutions so that they’d work on smaller devices. This is akin to accessibility remediation work.
Other businesses adopted mobile-first design methodologies, making mobile a key principle from which they worked. This is like doing accessibility beyond compliance.
An accessible-first approach, an approach that goes beyond compliance, invites the creation of more adaptable systems that are ready for situations we haven’t imagined yet.
With mobile, folks who had an adaptive, mobile-first methodology were able to take the introduction of tablets in stride, while those folks who’d been focused on only supporting the known form-factors had to do more work to keep up.
Product folks have an opportunity to bring “accessible-first” thinking to their work, and help cultivate a culture that strives for accessibility beyond compliance, and in so doing, ensure that we are all better prepared for anything that might come along.
A huge thanks to Josh and DK for sharing feedback with me while I came up with this presentation.
Some questions to consider:
- What are ways to interrogate your and your team’s assumptions?
- Are there tools that can help with this?
- What are some possible metrics that can be used to gauge the health of your team’s accessibility practice?
- How can you make those metrics meaningful for stakeholders?
- What are ways you and your team can celebrate your successes that can help set you up for more success?
- A higher-level kinda question: what is the role of a product person in helping to define a team’s culture?