Marketing leaders usually discover accessibility ownership problems the hard way: after an audit dump lands in their lap and nobody agrees who owns what. Tickets bounce. Release dates slip. The same issues keep coming back.
Treat each accessibility issue by what must change: content fixes update words/media and structure, design fixes update reusable components, and development fixes change underlying code or behavior and often require a developer.
This article gives you a simple, reusable model to sort each item into the right lane—content, design/system, or development—so you can stop arguing about ownership and start closing issues.
If you haven’t already, it’s worth reading our piece on how to spot when accessibility issues are coming from content workflow instead of the design system as a prerequisite; this article builds on that idea and extends it across all three lanes.
For a broader ownership view, pair this triage model with our guide to who owns accessibility defects found after launch. That article explains the governance problem; this one gives you the working classification step.
Why accessibility fixes keep bouncing between content, design, and development
When we review accessibility audits with marketing teams, we often see the same pattern:
- The audit export has 150–300 line items.
- The marketing lead must get them into the ticket system.
- Nobody agrees whether a given issue is copy, design, or code.
So tickets get misrouted:
- Alt text and headings are logged as “dev bugs.”
- Component contrast and focus styles are handed to content editors.
- JavaScript behavior issues are labeled as “design tweaks.”
Each team does what they can from their perspective, sends the ticket back, or marks it “won’t fix.” On the next release, scanners light up again with the same or slightly mutated problems.
That’s not a tooling problem. It’s a governance problem.
Two core patterns are usually at work:
- Workflow Debt. Accessibility decisions rely on one-off heroics instead of a repeatable way to classify, assign, and verify fixes. Every new audit adds more friction to an already fragile workflow.
- Ownership fragmentation. Multiple people can change the site, but no one clearly owns accessibility quality for content, components, and code. Without a shared model, each group assumes the others will handle “the tricky stuff.”
The result is a predictable consequence chain:
Messy audit → unclear ownership of fixes → ticket ping-pong and partial patches → recurring accessibility failures on new pages → growing Workflow Debt and risk → eventual need for heavier remediation or redesign.
You don’t fix that by sending every ticket to the developer or by announcing “accessibility is everyone’s job.” You fix it by agreeing how to decide where each fix belongs.
A simple three-lane model: content, design, and development fixes
The most reliable way to assign ownership is to ignore job titles for a moment and ask a single question:
What has to change in order for this accessibility problem to disappear everywhere it appears?
From that question, three lanes emerge.
| Lane | What changes | Typical owners |
|---|---|---|
| Content | Words, media, and page-level structure | Editors, marketers, content managers |
| Design / System | Reusable components, layouts, and styles | UX/UI, brand/design system owners |
| Development | Underlying code, templates, theme, and plugin behavior | Developers, technical vendors |
Use this lens:
- If fixing the issue means editing copy, headings, alt text, or media, it’s a content fix.
- If it means changing a reusable component or style so every instance is better, it’s a design/system fix.
- If it means modifying templates, theme code, or plugin behavior, it’s a development fix.
Notice what this model is not doing:
- It’s not asking where the problem shows up (for example, on a button in a hero banner).
- It’s asking where the fix needs to live so the issue stays fixed.
That distinction—where it shows vs. where it lives—is what stops tickets from bouncing.
Let’s walk each lane.
Lane 1 – Content-owned accessibility fixes
Content fixes are changes you can make inside the CMS editor without touching reusable components, theme settings, or custom code.
These issues live in the way your team uses the system, not in the system itself.
Common content-lane issues
If you can resolve it by editing content on a specific page or post, it probably lives here:
- Missing or unhelpful alt text on individual images.
- Headings skipped or misused (for example, a page starts at H3 for styling).
- Links that say only “click here” or “read more” without context.
- Wall-of-text sections with no lists, headings, or landmarks.
- PDFs linked from pages without accessible alternatives.
On a WordPress-style site, these are typically changes made directly in the block editor or page builder: updating image fields, adjusting heading levels, rewriting button labels, or restructuring content blocks.
How to decide it’s content-owned
Ask:
- Can an editor fix this safely with their existing permissions?
- Will the fix apply only to this page or a small set of pages?
- Does the audit message point to text, media, or per-page structure, not to a component that appears everywhere?
If the answer is “yes” to all three, it belongs in the content lane.
Ownership and workflow implications
In support work, we’ve noticed two common failure modes here:
- Alt text and headings are treated as dev work. Developers spend time fixing copy issues they’re not close to, and editors never build accessibility habits.
- Content fixes are done manually but never governed. There’s no checklist or training, so the same issues are reintroduced every campaign.
This is where earlier articles on content workflow come into play. If you recognize that many of your issues are really editorial habits, use our article on content workflow vs. design-system accessibility problems as an expansion on how to tune publishing behavior, not just templates.
To reduce Workflow Debt in this lane, you want:
- A simple editorial checklist that includes headings, alt text, link clarity, and basic structure.
- A review step for high-risk formats (for example, gated PDFs, webinar replays).
- A clear rule: if an issue is purely words or per-page structure, content owns it.
Lane 2 – Design/system-owned accessibility fixes
Design-system fixes are changes to reusable components and visual rules that multiple pages rely on: buttons, forms, cards, navigation, banners, and typography scales.
The issue might be reported on one page, but the fix should live where the component lives.
Common design/system-lane issues
You’re usually in the design lane when:
- Text or button colors don’t meet contrast standards in a standard component.
- Focus states are too subtle or missing on interactive elements.
- Tap targets are too small in a particular button style.
- Spacing or line height makes text hard to scan across the site.
- Components rely on color alone to convey meaning (for example, status labels).
These are problems with how the system expresses content, not with the content itself.
A recurring pattern we see: On multi-brand or campaign-heavy sites, editors keep rewriting copy to “work around” color clashes, while the underlying button styles never change. Contrast problems then reappear in every new campaign until someone formally owns a component-level fix in the design system.
How to decide it’s design/system-owned
Ask:
- Does the issue appear on multiple pages that use the same component?
- If we fix the underlying component or style, will that resolve dozens of issues at once?
- Can this change be made in your design system, style guide, or global theme settings without rewriting code logic?
If yes, it’s a design/system fix.
Ownership and workflow implications
This lane is where accessibility maturity jumps, because design decisions scale across your site.
But it’s also where we see subtle ownership fragmentation:
- Designers assume developers will “just implement accessible variants.”
- Developers assume designers will “hand off accessible specs.”
- Marketing assumes both are handling it, while focusing on campaigns.
To counter that, treat design/system ownership as explicit:
- Someone owns a living library of accessible components and states.
- When audits flag repeated issues in these components, tickets flow to that owner.
- Content editors are told: “Don’t hack this with inline styles; log a system issue.”
Our article on related guidance on website accessibility beyond isolated design elements expands this idea if you want to think in terms of patterns instead of one-off design tweaks.
If the design lane keeps expanding beyond component fixes, the next decision is whether the accessibility push is really a design refresh or a fuller UX rethink.
Lane 3 – Development-owned accessibility fixes
Development fixes require someone to modify or configure underlying code, templates, theme files, or plugin behavior.
These are changes that an editor or designer cannot safely achieve from the visual layer alone.
Common development-lane issues
Signals that the fix lives in code, not in copy or styling:
- Interactive components (menus, carousels, accordions) that are not keyboard-accessible.
- Missing or incorrect ARIA attributes in custom components.
- Form validation that only announces errors visually, not to assistive technology.
- Focus order that doesn’t follow the logical reading order because of custom layout code.
- Third-party widgets embedded without accessible configuration.
On a WordPress-like site, this usually involves:
- Updating theme or child-theme templates.
- Adjusting how the page builder outputs markup.
- Replacing or reconfiguring a problematic plugin.
How to decide it’s development-owned
Ask:
- Would a non-technical editor be taking on risk by attempting this fix?
- Does the issue stem from how the DOM is structured or how scripts behave, not from the words or color choices alone?
- Do we need access to code repositories, theme files, or plugin settings beyond the editor’s role?
If that’s true, it’s a development fix.
Scoping development work responsibly
This is where teams are tempted to dump the entire audit into “dev backlog” and hope for the best.
A better pattern:
- Use the three-lane model first; send only true dev items to development.
- Group similar dev items (for example, all issues with the same custom slider) into a single scoped task.
- Capture acceptance criteria in plain language: “Accordion can be operated with keyboard alone, announces expanded state to assistive technology, and focus order remains logical.”
Our article on what to clarify before a component-level accessibility fix is marked complete offers a useful contrast if you want to tighten how you define “done” for these kinds of development changes.
Borderline cases: When fixes cross lanes and need shared ownership
Not every issue falls neatly into one lane. Some touch content, design, and development.
Examples:
- A complex form with unclear labels (content), cramped layout (design), and inaccessible validation behavior (development).
- A hero carousel with auto-rotation (development), low-contrast overlay text (design), and vague headlines (content).
If you try to assign these as a single ticket to one team, you get classic ticket ping-pong: each group fixes “their” part and declares victory, but the whole experience remains broken.
Instead, use a primary lane with collaborators rule:
- Decide which lane is primary based on where the root problem lives.
- Name secondary collaborators explicitly on the ticket.
- Define completion as “all lanes addressed,” not “each team did something.”
For instance:
- Primary: development (make the carousel controllable and pauseable).
- Collaborators: design (define accessible text and control states), content (rewrite slides and headings).
This doesn’t need heavy ceremony, just a shared expectation that some fixes will span lanes and that partial fixes don’t close the ticket.
From individual tickets to a governance pattern
Classifying a few issues is helpful. Turning that into a habit is where you pay down Workflow Debt instead of adding to it.
In real teams, this usually means one person—often a marketing director or product owner—becomes the classification owner.
Their job isn’t to fix every issue. Their job is to:
- Classify each audit finding into a lane before it becomes a ticket.
- Name the primary owner (content, design/system, or development) on the ticket.
- Capture reusable decisions so future triage is faster.
A lightweight way to operationalize this:
- Add a mandatory “Accessibility lane” field to your issue tracker.
- Keep a one-page cheat sheet: common patterns for content, design, and dev.
- During backlog grooming, adjust misclassified lanes rather than debating from scratch.
Over time, the pattern becomes self-reinforcing:
- Editors learn which issues they can own and which need a system change.
- Designers learn to treat accessibility as a first-class requirement of components.
- Developers receive fewer, better-scoped tickets.
If you want to see how content publishing speed can quietly reintroduce problems even after you’ve cleaned up templates, our article on related guidance on why accessibility problems return when content changes faster than review is a useful escalation of this governance idea.
The goal isn’t perfection. It’s to replace ad hoc heroics with a stable, predictable way to keep accessibility from drifting as your site evolves.
When that stable pattern requires ongoing design-system and front-end stewardship, the related article on when web design and development needs an ongoing ownership model is the natural next step.
When to bring in outside accessibility support
Even with a solid three-lane model, there are times when internal capacity, expertise, or platform complexity mean you shouldn’t go it alone.
Signals that it’s time to get help:
- Your audit backlog is large, and issues keep aging out rather than closing.
- You see the same few root patterns (for example, component contrast, form behavior, link patterns) across dozens of pages.
- You’re about to invest in a redesign or major theme change and don’t want to reintroduce known issues.
In those situations, the work isn’t just “fix these 200 items.” It’s:
- Validate your three-lane classification against real-world patterns.
- Tighten how content, design, and development hand off fixes.
- Turn scattered efforts into a maintainable operating model.
Our Website Accessibility (WCAG Compliance) service is designed to operationalize exactly this: we look at your current site, audit outputs, and team structure, then help you establish a sustainable fix workflow that assigns issues to the right lane and keeps them there as the site changes.
If you’re staring at a long audit export and can already see ticket ping-pong coming, the next practical move is simple: share that export with us and start a conversation about how classification and ownership should work on your site. You can use the contact form on the site to outline your current audit situation, who’s on your team, and where you feel ownership is fuzzy, and we’ll respond with a concrete proposal for how to untangle it.
Finally, if you want to keep building your own expertise, the broader set of related accessibility guidance on our blog offers additional context on governance, recurring failure modes, and how accessibility fits into long-term website support.
The underlying decision is this: either you let accessibility ownership stay ambiguous and absorb the ongoing Workflow Debt, or you adopt a clear three-lane model and deliberately assign someone to own classification. One path leads to recurring audits that never quite land; the other turns accessibility into a manageable part of running a serious website.