Accessibility Is Everyone’s Job, Which Is Why It’s Nobody’s

Ask a team who owns accessibility and you’ll usually hear “all of us.” That’s the right value. But in practice, it’s often the reason the work never gets done.

I’ve seen it plenty of times. The issues get found, everyone agrees they matter, and then they sit in the backlog. Nobody decided to ignore them. They just never belonged to anyone, so they never made it to the top of anyone’s list.

I’ve also been on the other end of it. For most of my career, I was the lone accessibility person on the team. That doesn’t work either.

Two ways accessibility ownership goes wrong

The first is the one I just described: nobody owns it. An automated scan finds problems. Someone files tickets. And then every week there’s something more urgent: a client deadline, a launch, a bug that’s costing real money.

An unlabeled form field doesn’t feel urgent to anyone in the sprint planning meeting. It’s urgent to the people who can’t submit the form, but they aren’t usually in the meeting.

The second is one person owns all of it. Every design review, every question, every test, and every “is this okay?” goes to the same person. They become the bottleneck without meaning to. Everyone else stops building their own skills, because why would you when there’s someone to ask? And when that person is busy, on vacation, or moves on, the team’s accessibility knowledge goes with them.

Last year I wrote that this work “has a way of always falling on the shoulders of the same small group of people.” I’ve been one of those people, and I have a lot of affection for everyone else who has. But a team that depends on one person for accessibility has a single point of failure.

These look like opposite problems, but they come from the same place. Nobody broke the work into pieces small enough to hand to specific people.

Accessibility is at least three jobs

A team that depends on one person for accessibility has a single point of failure.

When people say “accessibility,” they usually mean one big, vague thing. In practice, it’s several different jobs that need different skills.

Review. Automated scanners flag plenty of things they can’t confirm on their own. Is this alt text accurate? Is that bold line of text really a heading? Someone with judgment has to look at each one and decide. When nobody owns review, those potential issues pile up, or someone dismisses them in bulk to make the number go down.

Test. This is the part scanners can’t do at all. Tab through the checkout with a keyboard. Fill out the contact form with a screen reader. Zoom the page to 400% and see what breaks. Manual testing takes real time on the calendar, and it needs someone who knows what to look and listen for.

Fix. Changing the code or the content. Developers handle most of it, but alt text, headings, and link text usually belong to whoever writes and publishes the content.

Then there’s a fourth job that ties the other three together: owning the queue. That means deciding what gets fixed first and making sure it lands on someone’s plate. The queue owner doesn’t do all the work. They make sure the work keeps moving.

Splitting accessibility up this way is what lets the accessibility person stop being the only person. A content editor can own alt text without ever learning ARIA (Accessible Rich Internet Applications). A developer can fix a keyboard trap without being the one who found it.

Put a name next to each job

The queue owner doesn’t do all the work. They make sure the work keeps moving.

Here’s how this tends to map onto a typical web team:

Designers own color contrast, visible focus states, and target sizes before anything gets built. Catching a contrast problem in a mockup takes a few minutes. Catching it after launch means a ticket, a code change, and another round of review.

Content editors own alt text, heading structure, and link text, every time they publish.

Developers own fixes in the code, plus a quick keyboard check before they call something done.

Someone in quality assurance, project management, or your accessibility lead, if you have one, owns manual testing on a regular schedule, and not only in the week before launch.

One person owns the queue.

On a small team, one person might wear three of those hats, and that’s fine. Headcount matters less than making sure every job has a name next to it, so nothing depends on someone happening to notice.

The queue owner’s job sounds like the smallest one on the list. I’d argue it matters the most. On my own team, we keep track of our accessibility issues, and every week we make sure a few of them get tackled. Not all of them. A few. It sounds almost too simple, but that’s how a list gets shorter instead of longer.

I made a similar point in our 2026 accessibility game plan back in January: small, consistent actions compound. Giving the queue an owner is how that consistency survives a busy month.

Who owns accessibility after launch

Agencies have an extra handoff to worry about. The site launches, the agency moves on to the next project, and the client assumes the agency is keeping an eye on accessibility. The agency assumes the client is. Meanwhile, new content goes up every week and plugins get updated.

Settle it in the contract. Who monitors the site after launch? Who fixes what the monitoring finds? Who pays for it?

I’ve written before about the accessibility conversation agencies avoid with their clients, and about why accessibility was never a one-time purchase. Post-launch ownership belongs in that same conversation, and it belongs there before the launch date.

What “everyone’s job” should actually mean

Shared responsibility for noticing, and clear ownership for doing.

I don’t want teams to stop saying accessibility is everyone’s job. I want the phrase to mean something specific.

Everyone notices and flags. The designer who spots low contrast in someone else’s mockup says so. The writer who sees an image without alt text speaks up. The project manager asks, “Did anyone try this with a keyboard?”

And then each piece of the work has one name next to it. Shared responsibility for noticing, and clear ownership for doing.

So here’s my question. If I asked five people on your team who owns accessibility, how many different answers would I get? If the answer is “all of us,” or nobody’s sure, or it’s the name of one tired person, pick one of these jobs this week and put a name next to it.