Don't Water It Down

Published 2015-07-14 · Updated 2026-06-23 · By Alan Wizemann

Topics: User Experience, Product Strategy & Development, Growth Leadership, Mobile Development

A few years into my time at Target, I was asked to speak at the National Federation of the Blind's national convention about the work we were doing on accessibility, and I have given a lot of talks over the years. That one rearranged how I think about building products, and it did so in a way I did not see coming when I walked into the room. The mission I had given my teams was simple to say and genuinely hard to do: be 100% accessible across all of our experiences, regardless of the device a guest happened to be holding. Not "accessible enough to satisfy the requirement." Not "accessible on the website, eventually, for the parts that are easy to get to." All of it, every experience and every device, the same guest journey for everyone who walked in the door, real or digital.

The reason that mission has actual teeth is hidden inside a single small word, and that word is same. The instinct in most organizations, when they finally take accessibility seriously, is to build a separate path off to the side, a stripped-down version, a simplified flow for people with different abilities that sits politely next to the real product. It feels generous when you do it, like an act of care. It is actually closer to the opposite of that. The most important thing I learned, and it came directly from the very people we were building for, is that they do not want a watered-down or different experience handed to them – they want to be treated the same as everyone else, full stop.

One of our accessibility leaders, who is blind himself and worked on our mobile apps, framed it for me before that talk far better than I ever could have framed it on my own. The real problem facing blind people, he told me, is not blindness itself at all – it is the misconceptions about it. At its core, blindness is a lack of access to information (nothing more mystical than that), and what he and most of the people in that convention room wanted was not to be put up on a pedestal. It was simply to have the playing field leveled. That single reframe changes the entire engineering problem, because accessibility stops being a compliance checkbox or a charitable act and becomes what it honestly always was: a question of whether your product delivers the same information and the same capability to everyone who is trying to use it. Once you see it in that light, a separate "accessible version" looks like exactly what it is, which is a polite way of saying "this is not really for you, so here is a smaller thing off to the side instead."

This is also where I learned to connect two ideas that most companies stubbornly keep in separate rooms, which are mobile and accessibility, because to me they are very nearly the same word. The mobile device is the great equalizer of our moment. It ships with assistive technology built right into the operating system, screen readers and magnification and voice control that millions of people already use fluently every single day, and if you build your experience to integrate cleanly with those native capabilities instead of fighting against them, you unlock your product for an enormous number of people without ever building anything separate at all. The device already did the hard part for you. Your only real job is to not break it.

The actual work followed from that principle rather than from any checklist, which matters more than it sounds. Web experiences built and certified to a real accessibility standard rather than quietly self-graded. Apps on both platforms that integrated deeply with the device's own accessibility features instead of reinventing them badly in-house. In-store mapping and location systems to help people navigate the physical store, because accessibility very much does not stop at the edge of the screen. And early exploration of wearables and associate devices as assistive tools, because the next equalizer is always arriving sooner than you expect, and you want to be ready to use it the same way you used the last one.

What genuinely surprised me, though in hindsight it absolutely should not have, is how much building for the hardest case improves the product for everyone else, too. When you force an experience to work cleanly all the way through a screen reader, you suddenly discover all the places where your information architecture is muddled, where your labels are vague and unhelpful, and where the path to the thing the customer actually wants is far longer than it ever needed to be. Fixing every one of those for accessibility quietly fixes them for everybody, and the constraint, far from limiting you, makes the whole product clearer than it was before. I have never once seen a team take accessibility seriously and end up with a worse experience for sighted users. In my experience it goes the other way every single time.

There is a leadership lesson sitting underneath the technical one, and it is the part I would press on hardest if I had your attention for only a minute. Accessibility is, at bottom, a statement about who you actually think your customer is. To be accessible is to be honest, open, and approachable by anyone who shows up, and the very moment you carve out a separate, lesser path, you have quietly decided that some of your customers are a secondary concern – a special case to be handled rather than guests to be served like everyone else. Teams can feel that decision even when no one ever says it out loud, and it reliably shows up in the product they build.

I am not going to pretend that we finished the work or got every last thing right, because that would be its own kind of dishonesty. A goal like 100% is a direction you walk in, not a finish line you cross, and accessibility is the kind of thing that needs continuous ownership rather than a single launch and a triumphant victory lap. But the principle holds, and it has become the way I expect my teams to build, full stop. Build one experience and make it work for everyone who comes to it. Do not build a smaller version for the people you happen to find harder to serve, because the smaller version is itself the message, and that message is the wrong one. Treat people the same. That was the request I carried home from that convention, and it turned out, somewhat to my surprise, to have been the whole strategy all along.