Who Actually Owns Accessibility

Ask an organization who owns accessibility and you get one of three answers. "IT." "Our web vendor." Or the worst one: "everybody, really — it's a shared responsibility."

Shared responsibility with no named owner is how a remediated site drifts back within a year.

Why the common answers fail

IT owns infrastructure and often the CMS. They don't write the alt text, choose the brand palette, record the video, or publish the PDF. Most accessibility failures originate outside IT.

The web vendor owns what they built, in the version they delivered. They don't own the content published since, the platform procured last quarter, or the documents uploaded this morning.

Everyone owns nothing. Without a name attached, accessibility loses every prioritization conversation it ever enters, because whoever raises it is volunteering rather than doing their job.

One accountable owner, several responsible roles

The distinction that matters: one person is accountable for the program; several roles are responsible for their piece.

The accountable owner is a single named person with enough authority to stop a launch. They don't do the work. They own the standard, the policy, the testing cadence, the training plan, and the escalation path when something is going to ship broken. In a mid-sized organization this is usually a digital or communications director. In a large one it's often a formal accessibility coordinator or program manager.

The ability to say "this doesn't ship" is what makes the role real. Without it, you have a coordinator who writes reminder emails.

The responsible roles each own a short, specific list:

• Content authors — headings, link text, alt text, table structure, accessible documents.
• Designers — contrast, focus indicators, target size, not conveying meaning through color alone, form patterns.
• Developers — semantic markup, keyboard operability, name/role/value for custom components, status announcements, automated checks in the build.
• Procurement — asking for a VPAT, evaluating it rather than filing it, and putting accessibility language in contracts and renewals.
• Marketing — campaign pages and email built to the same standard as everything else, which is where conformance most often leaks.
• HR — the careers site and application flow, plus a working accommodation path.

Nobody on that list needs deep expertise. They need to know the four or five things their role can get wrong.

Three mechanisms that make it stick

A written policy. Two pages naming the standard, the scope, the owner, and how exceptions get approved. If nothing is written down, the standard changes whenever someone is under deadline.

Accessibility in the definition of done. A design isn't approved without a contrast check. A pull request isn't merged if automated checks fail. Content isn't published without an accessibility review step. Built into the workflow, it stops being optional without anyone having to argue for it.

A feedback path that works. A published contact, a defined response time, and a record of how reported barriers were resolved. This is both the right thing and the most useful evidence you can have if a complaint ever arrives.

Where it usually goes wrong

Organizations appoint an owner without authority. Someone is made "accessibility lead" on top of a full workload, with no ability to delay a launch and no budget. Six months later they're exhausted and the site is drifting.

If the role is real, it comes with three things: named time, a seat in launch decisions, and the standing to hold the line when a deadline gets tight.

That's the whole test. If nobody in your organization can stop a launch over an accessibility defect, then nobody owns accessibility — regardless of what the org chart says.