Skip to footer navigation.

« Oatmeal

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.

Picture of a slide with the title “Why though?” It also includes a quote from Kat Holmes’ book Mismatch. The quote reads: “There are many challenges that stand in the way of inclusion, the sneakiest of which are sympathy and pity. Treating inclusion as a benevolent mission increases the separation between people. Believing that it should prevail simply because it’s the right thing to do is the fastest way to undermine its progress. To its own detriment, inclusion is often categorized as a feel-good activity.”

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:

This slide shows a meme in three parts. The first part shows a small, pixelated image of Mario. The middle part shows the fire flower. The last part shows a larger version of Mario throwing a fireball. Beneath each section is some text. The text, in aggregate, is set out like an equation, and reads: “Person who’s a potential customer + your product = awesome person who can do rad shit!” An arrow points to the fire flower and is labeled “this isn’t what your business make.” Another arrow points to Mario throwing a fireball and is labeled “this is what your business makes.”

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.

Image includes a quote that reads: “A person seeking help in a time of crisis does not care about TypeScript, tree shaking, hot module replacement, A/B tests, burndown charts, NPS, OKRs, KPIs, or other startup jargon. Developer experience does not count for shit if the person using the thing they built can’t actually get what they need.” from Modern Health, frameworks, performance, and harm, by Eric W. Bailey

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.

The same meme as earlier, again in 3 parts, but with some changes. Now it has been edited. A large letter X, labeled “Not Accessible” totally covers the fire flower. And, the previously fire-ball-throwing Mario now faces outwards, looking at the viewer. Above Mario’s head float 3 question marks, indicating that Mario is very confused.

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.

Slide with the text “How though?” and a small picture of Mario looking at the floating text.

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.

Slide with the text “Identify points of exclusion.”

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.

Slide with the text “How though?” and a small picture of Mario appearing to walk with his arms’ outstretched.

Again, how though? How can we identify points of exclusion…especially when we’re talking about something that hasn’t been built yet?

Slide with the text “Interrogate your assumptions.”

We start by examining the assumptions we’ve made and making sure that they are informed by research, and also informing new research.

The popularization of hashtags on twitter is an example of this, or a child climbing a counter to reach a cabinet in a kitchen.

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.

Slide with the text “Have metrics to track your practice.” and a small picture of Mario appearing to recoil in fear.’ outstretched.

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.

Slide with the text “Always be banging that drum.”

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:

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.

Slide with the text “Thanks!” and a small picture of Mario. Mario has the ears and tail of a racoon, and is holding a bejeweled wand over their head.

A huge thanks to Josh and DK for sharing feedback with me while I came up with this presentation.

Slide with the text “Discussion.” and a picture of Mario curled into a small ball, hiding beneath their hat. The slide also lists the questions listed in the next section of this document.

Some questions to consider: