Too Many Cooks Spoil Accessibility — Unless You Map The Cooks

Imagine building a website and saying “Accessibility? Oh, devs will do that later.” The problem is, when “later” rolls around, everyone’s pointing at everyone else. The designers say “I didn’t know alt text was your job,” content folks say “I thought you’d structure the headings,” and developers say “I have too many other tickets.” Result: accessibility becomes the leftover side dish nobody wants to eat.

Enter ARRM — Accessibility Roles and Responsibilities Mapping — a draft W3C / WAI resource designed to ensure accessibility isn’t an accidental afterthought.

What is ARRM?

In short, ARRM is a framework (still draft) that helps teams divide up who is responsible for what when it comes to satisfying WCAG’s success criteria.

The idea: for each accessibility-related task, each role in your product team (UX, visual design, content author, front-end developer, maybe QA, etc.) can be assigned one of three levels of involvement:

• Primary — The role ultimately owns the accessibility task
• Secondary — They co-help or supply important inputs
• Contributor — Consulted or informed, but not hands-on owner

So instead of devs getting stuck with all tasks by default, you map tasks from WCAG to roles up front.

Example: for heading structure

• Content authors produce the heading text, decide levels
• Designers decide how headings look (size, styling)
• Developers code the heading markup Each of those roles has a defined “slice” of the responsibility.

ARRM provides a decision tree to guide you through assigning ownership per task or success criterion.

Why Bother with ARRM?

Because without clarity, accessibility tends to be shoved onto whichever role is left standing (usually dev). As some commentators note:

"Blaming devs for every accessibility bug is like blaming the compiler for bad logic — accessibility isn’t a single function; it’s the whole program."

Here’s what ARRM helps you achieve:

1. Clear accountability — no confusion about who does what
2. Better collaboration — roles talk to each other early; handoffs are smoother
3. Reduced bottlenecks — devs aren’t overloaded with tasks outside their domain
4. Scalable for organizations — you can adapt ARRM to your specific team structure

In short: accessibility is more function than feature, and ARRM helps you assign the subroutines properly.

Inside ARRM: Roles, Tasks & Decision Tree

Let’s peek under the hood.

Roles

ARRM starts with a set of “typical roles” — UX designer, visual designer, content author, front-end developer — but it encourages you to customize for your organization. You might also include QA/testers, product managers, etc.

(More about roles)

Tasks & WCAG Success Criteria

ARRM provides a draft tasks mapping: it links common accessibility tasks (e.g. alt text, heading structure, form labels) to WCAG success criteria, and shows which roles should have primary, secondary, or contributor responsibility. For example, in the “Images and Graphs” section:

• IMG-001 (WCAG 1.1.1): “Informative alternate text is provided for images” → Primary: Content Author
• IMG-003: decorative images null-alt → Primary: Front-End Dev, Secondary: Content Author And so on.

This is not exhaustive, but a starting point.

(More about tasks) - (More about Success Criteria)

Decision Tree

For tasks not already in the default mapping, ARRM offers a decision tree: you walk through a set of guiding questions to figure out assignment. (E.g. Which role has the domain knowledge needed? Which role is in the best position to act?) It’s like a flowchart for accessibility ownership.

You can choose to assign responsibility per WCAG criterion (coarser grain) or per task/checkpoint (finer grain) depending on your team’s needs.

(More about decision tree)

How to Use ARRM in Practice (Yes, There’s Homework)

Here’s a suggested workflow:

1. Gather the team — get UX, content, dev, QA, product leads in the same room (or virtual room).
2. List your accessibility tasks / success criteria — maybe using ARRM’s master list as reference.
3. Run the decision tree / mapping exercise — assign primary, secondary, contributor roles for each task or criterion.
4. Document it — you want a living mapping you can refer to and revisit.
5. Use it in planning & sprints — when new features or content arise, consult the mapping: don’t guess who should handle accessibility.
6. Iterate — over time, refine the mapping to match your real workflows.

A key benefit: new team members can look at the mapping and immediately see “who owns alt-text,” “who handles focus order,” etc.

You might say ARRM helps you avoid the dreaded “Oh, I thought you were doing it” syndrome — it’s punny, but true.

Challenges & Considerations

• It’s a draft — ARRM is under development; feedback is welcomed.
• Smaller teams may have overlapping roles — in that case, one person may take multiple responsibilities; mapping is more flexible than rigid.
• Some tasks cross domains (e.g. animations, ARIA) — thoughtful discussion is needed.
• The mapping doesn’t itself guarantee conformance; it helps with accountability and planning, but you still need evaluations and testing.
• If your organizational culture resists “extra documentation,” getting buy-in is essential — this mapping must be seen as a tool, not red tape.

Wrapping Up — Let ARRM Be Your Accessibility Compass

If you're building or maintaining web products and want accessibility to be baked in (not just sprinkled on top), ARRM is a promising compass. It helps you chart who does what and avoid the “someone will fix it later” quagmire.

In essence, ARRM is a responsibility GPS for accessibility — guiding your team through the maze of WCAG obligations without veering off into “blame zone.” (Yes, I’ll stop punning now.)

If you're feeling nerdy: grab the draft, experiment with it, and contribute feedback via GitHub. Accessibility is for everyone — and ARRM helps make sure everyone knows their role in making it so.