The responsibility objection to accessibility


Of all the objections I've heard, responsibility might the most slippery.

It feels like cheating.

Time and money are at least honest. Someone's telling you directly that they're not willing to commit. But responsibility is different. They won't say no to your face. It doesn't even sound like an objection. It sounds like a process. "That goes through the dev team." "It gets picked up in QA." "We have a workflow for that."

It sounds like someone's handling it, just not them.

So who is handling accessibility if not them? Who owns it?

Nobody owns accessibility because everybody owns accessibility.

Accessibility doesn't have a natural home. Development thinks it's a design problem. Design thinks it's a development problem. Content thinks it's technical. Marketing thinks it's product. Product is too busy shipping features to stop and care.

So it lives in the gaps between all these teams. Things that live in the gaps never get done.

This is what makes responsibility the most slippery objection of the lot. Time and money objections at least keep the conversation alive. The responsibility objection ends it quietly.

It's one of the few objections that cuts across seniority. A junior developer says it. They don't know better. A senior designer says it. They know but consider it a technical issue. A head of product says it. They know it needs to be done, but they're not the one doing the work, so why bother?!

Accessibility genuinely touches every discipline. And this paradoxically makes it easier for every discipline to say no. The more people who are theoretically responsible for accessibility, the less likely any one of them is to act on it.

This obviously ties in with time. Everyone's limited by time so if they can pass accessibility to someone else, that saves them time. Do that enough times and you'll start thinking accessibility was never your responsibility anyway.

That's wrong.

If your work touches the product in any way, accessibility is partly yours.

A developer who writes inaccessible code owns that code. A designer who designs inaccessible components owns those components. A content writer who publishes unstructured pages owns that.

The fact that someone else also owns a piece of it doesn't reduce your share.

Shared responsibility isn't the same as no responsibility.

Accessibility isn't the only discipline that has more than one owner. In fact, most shared disciplines have more than one person responsible for it. Security and performance both have developers and QA responsible. Quality has everyone on the product team responsible for it. And when things slip, there's usually someone whose job it is to notice.

Accessibility is unique in how completely it can disappear despite being everyone's job. There's no alarm that goes off. There are no numbers to watch. Accessibility just quietly gets worse with every sprint, every release and every new feature shipped without anyone asking the right questions.

So if it's everyone's job, what does that mean?

Someone has to say so explicitly.

Responsibility is not about who owns accessibility. Responsibility masquerades as process. And what's worse, it masquerades as a process that's working! Time sounds like overwhelm. Money sounds like constraint. Responsibility sounds like a system that's working.

But it isn't.

Responsibility is the most convincing objection of the lot. And the most damaging at the same time.

And the standard response of making "someone" own it doesn't really work. You can't just tell a product team to designate someone to care more.

The only practical answer is to make those gaps in the process visible and to make it cheap to claim responsibility.

People avoid responsibility because they assume it means doing everything. If you can show someone that owning accessibility doesn't mean solving it single-handedly, suddenly it's a much easier thing to put your hand up for.

Most teams already have someone doing this informally. There's usually one person who notices when something's wrong, who asks the awkward questions and cares just enough to flag it. They just don't have the language or the authority to make it stick.

The solution becomes to find that person and give them authority, formally.

Ship accessible websites. Faster.

Join fellow like-minded product owners looking to learn and contribute to authentic conversations on accessibility and inclusive design packed into just 5 minutes a day.

Read more from Ship accessible websites. Faster.

I don't think it's ever too late to think about accessibility and improve your product for people who need it. It just gets more expensive the later you do it. If you started thinking about accessibility because you got a complaint or you freaked out because of an audit, you might think, well, it's too late now. I hear you! That's okay. But it's not too late and there's no need to freak out. You're here now. And there's lots you can do to improve your situation. The cost is higher, but you...

I got this question earlier this month. I'm paraphrasing a little bit for clarity, but it goes a bit like this: We think it'd be better to start working with accessibility a bit early in the process next time. Wouldn't that save some work later on? How early is early enough? First off, yeah, it warms my heart when I hear stuff like this coming completely unprompted. So how early is early enough to start thinking about accessibility in the software development lifecyecle (SDLC)? Follow the...

If you've never had a headache so bad you needed bigger text or you've never watched a video on mute in a waiting room, of course you're going to think accessibility is about disabilities. But accessibility isn't about disabilities. It never was. This idea that it's a niche concern for a minority of "people with disabilities" is one of the most damaging myths in design history. To be honest, I have no idea if subtitles weren't built for the deaf. But I know it would have taken me longer than...