How to Tell When Website Accessibility Issues Are Coming From Content Workflow, Not the Design System

You’ve fixed accessibility problems. You’ve refreshed templates. Maybe you even ran a full audit.

And yet: new pages keep failing basic checks, specific campaigns attract complaints, and issues you thought were “done” quietly reappear.

At that point, you’re not really asking, “Is our site accessible?” You’re asking something more operational:

Do we have a design system problem, or a content workflow problem?

That’s a different decision entirely. It determines whether you should:

• Rebuild components and templates, or
• Change how content is planned, produced, and published.

Most recurring website accessibility issues come from how content is created, reviewed, and published day to day—not from the design system itself. If the same issues only appear on certain pages or from certain teams, if they started after a publishing change (new content types, more authors, faster cadence), and if they can be fixed without touching templates or code, you are dealing with a content workflow problem. In that case, improving editor training, checklists, and review steps will reduce accessibility risk far more than another design refresh.

This article walks through a simple way to diagnose where your issues are coming from and what to change if the real problem lives in your content workflow.

If you want a broader orientation first, you can skim our overview of common accessibility issues and then come back here to decide where they’re really coming from.

---

1. The real decision: design system problem or content workflow problem?

When accessibility keeps slipping, most leaders default to a familiar move: “Do we need to redesign the site?”

Sometimes, yes. But often, the underlying design system is fine. What’s breaking accessibility is how the organization is using it.

In practice, you’re almost always looking at one of three situations:

1. Design system problem – core templates and components are flawed. Even a perfect editor can’t publish an accessible page.
2. Content workflow problem – templates are sound, but day-to-day practices bypass accessibility (no alt text, broken headings, bad link text, etc.).
3. Mixed ownership problem – the design system has gaps and editors are using it in risky ways.

Why this matters to you as a marketing, operations, or business leader:

• Design system problems are largely solved via development work, pattern library updates, and testing. It’s a project.
• Workflow problems are solved by changing how content flows through your organization: roles, training, checklists, and guardrails. It’s ongoing.
• Mixed problems require coordination: fix the worst systemic issues and stop reintroducing them via content.

Your budget, timeline, and ownership model will look completely different depending on which one you’re dealing with.

The rest of this article helps you classify what you’re seeing so you don’t commission another design project when what you really need is a content governance change.

---

2. Quick triage: three patterns that usually mean “this is workflow, not design”

If you’re trying to diagnose this quickly, look for these patterns first.

Pattern 1: Problems cluster around specific pages, authors, or teams

Ask your team or vendor for a list of recent accessibility issues. Then, instead of scanning the technical details, look for who or where:

• Do the same issues keep showing up on campaign landing pages but not on your core product pages?
• Are blog posts from certain authors missing headings and alt text, while others are clean?
• Are partnership or event pages worse than evergreen content managed by your central team?

If the problems map cleanly to specific teams or page types, you’re seeing behavior, not a systemic design flaw.

Pattern 2: Issues started after a publishing change

Think back to when accessibility complaints or scan failures picked up. Did any of these happen around the same time?

• You added new content formats (long-form guides, gated assets, interactive explainers, etc.).
• You gave more people publishing access in the CMS.
• You increased content cadence (e.g., weekly webinars, multiple campaigns per month).
• You introduced a new content type (e.g., resource library, event hub) without a deliberate review step.

We’ve written separately about why issues resurface when new content formats are added without review and when new content types are published without editorial guardrails. The pattern is always the same: the system didn’t change, but how content moves through it did.

When the spike in issues lines up with a publishing change, that’s almost always a workflow signal.

Pattern 3: Issues can be fixed directly in the editor, without touching code

Look at a few example pages with known problems. For each one, ask a simple question: Could an editor fix this using only the CMS?

If the answers look like:

• “We just need to add alt text and fix headings.”
• “We should change that ‘Click here’ to meaningful link text.”
• “We embedded the video but didn’t add captions or a transcript link.”
• “We pasted formatted text from a document and it turned into a mess of nested headings.”

…then you’re in workflow territory. A developer isn’t required; the issue lives entirely within content decisions.

We dig deeper into this pattern in our post on how routine content updates reintroduce accessibility problems.

If all three patterns sound familiar, it’s safe to assume you have a content workflow problem, even if there are also some design system gaps.

---

3. When it really is the design system (and how that looks in practice)

To be fair to your content team, you should also know what a true design system failure looks like. In those cases, editors can follow every rule and still publish inaccessible pages.

You’re likely facing a design system issue if:

Issues appear consistently across templates, regardless of content

For example:

• Every form on the site is missing labels for screen readers.
• All buttons are low-contrast, even with short, plain text labels.
• The primary navigation can’t be operated with a keyboard on any page.

If you can spin up a blank page, drop in a component with no real content, and it’s still inaccessible, that’s a design problem.

Problems track with components and patterns, not authors

Look for issues like:

• A particular card component never exposes a proper heading level.
• Your carousel or slider can’t be paused or navigated without a mouse.
• A reusable hero block forces heading levels that break logical order.

Here, the problem shows up wherever the pattern is used, even by your most careful editors. That’s the subject of our piece on why accessibility problems return when reusable components are not reviewed.

Fixes require developers or designers, not just content editors

When you look at a failing page and your team says:

• “We need to add ARIA attributes or adjust focus states.”
• “We have to adjust the base font size or color tokens.”
• “We need to change how the component output is structured in the DOM.”

…you’re clearly in design system territory.

Design system issues are absolutely worth fixing; they affect every future page. But they’re only half the story. Even a perfectly accessible design system can be undermined by poor content workflows.

---

4. A simple diagnostic framework: page-level, pattern-level, and workflow-level issues

To get from hunch to decision, you don’t need a 100-page report. You need a way to classify what you’re seeing.

Here’s a simple three-bucket framework you can use with your team or vendor.

Bucket 1: Page-level issues (one-off content errors)

These are problems that:

• Show up on individual pages
• Can be fixed directly in the CMS
• Don’t obviously repeat across a whole template

Examples:

• Missing alt text on a specific blog post.
• A single landing page with a broken heading hierarchy.
• One PDF download with no accessible alternative.

What it implies:

• Not a design system failure.
• You likely have training gaps, weak checklists, or no enforcement in your editorial process.

Bucket 2: Pattern-level issues (reusable components and templates)

These issues:

• Repeat wherever a component or template is used
• Often require dev/design changes
• Are visible even on content-light or test pages

Examples:

• A CTA block that always renders button text too light.
• A page template that forces H1 > H3, skipping H2.
• A modal component that traps keyboard focus.

What it implies:

• A design system problem that should be addressed centrally.
• Editors can’t reasonably fix this on their own.

Bucket 3: Workflow-level issues (publishing habits and governance)

These issues:

• Correlate with teams, authors, or time periods
• Flare up around launches, new formats, or fast content cycles
• Often reappear after being “fixed” once

Examples:

• Campaign pages regularly launched without alt text or proper headings.
• Partner or regional teams creating microsites that ignore accessibility guidance.
• Webinars and events posted without captions or transcript links, then quietly updated after complaints.

What it implies:

• A governance and workflow problem.
• You need clarity on roles, expectations, and pre-publish checks.

In practice, you’ll see a mix of all three buckets. What matters for your decision is which bucket dominates:

• Mostly pattern-level issues → prioritize a design system and component review.
• Mostly page- and workflow-level issues → prioritize editorial workflow changes, training, and light guardrails.
• Mixed but heavy on workflow → address the worst components, then invest in governance so you stop reintroducing problems.

---

5. Common content workflow failures that quietly break accessibility

Once you see you have a workflow problem, the next question is, “What exactly are we doing that keeps breaking this?”

Here are the most common patterns we see inside marketing and content teams.

1. Pasting directly from design tools or documents

Design or content teams work in Figma, PowerPoint, or Google Docs; then someone copies and pastes into the CMS.

Results:

• Headings come in as styled paragraphs instead of semantic heading tags.
• Lists and emphasis get lost or converted into weird nested markup.
• Spacing that looked fine in a deck breaks screen reader logic.

2. Untrained authors skipping alt text and headings

When many people can publish, but no one has been trained on accessibility basics, you get:

• Decorative images treated like content, and vice versa.
• Alt text that just repeats captions or is left blank altogether.
• Long pages with no meaningful headings, just bolded text.

None of this requires a developer to fix. It requires letting authors know what “good” looks like—and expecting it.

3. New formats added without guardrails

New content formats are a classic source of regressions:

• Long-form research reports with complex charts.
• Interactive explainers and calculators.
• Video-heavy resource hubs.

If you add these without a plan for captions, transcripts, data table alternatives, or keyboard behavior, you’ve just created a new channel for accessibility failures. We explore this in more detail in our article on why accessibility issues return when new content formats are added without review.

4. Last-minute uploads that bypass review

Common operational reality:

• “The webinar is tomorrow; just get the page live.”
• “Legal approved the PDF five minutes ago; please upload it now.”

When timing pressure hits, accessibility and QA are the first steps to go. Over months, those rushed exceptions become your risk profile.

5. Over-reliance on automated scans without editorial follow-through

Automated scanners are good at catching:

• Color contrast
• Missing alt attributes
• Form labeling issues

They’re bad at evaluating content choices, such as:

• Whether alt text is meaningful.
• Whether link text makes sense out of context.
• Whether headings actually reflect content structure.

Teams that “pass the scan” and move on, without human review, keep shipping content that is technically improved but still hard to use.

We’ve also covered how problems creep back in when content changes faster than review. That’s a workflow design problem, not a tooling problem.

---

6. Testing your diagnosis: three low-friction experiments to run this month

You don’t need to guess. You can test whether workflow is driving your accessibility issues with a few simple experiments.

Experiment 1: Sample across teams and page types

Pick a small set of pages:

• 3–5 from marketing campaigns
• 3–5 from your blog or resources
• 3–5 core product or service pages
• 3–5 owned by another group (partners, HR, investor relations, etc.)

Run a light review—manual or via your existing vendor—and then look at patterns by owner.

If one group’s pages consistently have more basic issues, you’ve found a workflow and training gap, not a global design failure.

Experiment 2: Compare “before and after” a publishing change

If you recently:

• Increased publishing cadence
• Added a new content type
• Expanded author permissions

…pull scans or issue lists from before and after that date.

Look specifically for:

• New issue types that appeared only after the change
• Repeated issues on the new content type or format

If the spike lines up with the change, that’s powerful evidence you need new guardrails around that workflow.

Experiment 3: Tighten pre-publish checks for one stream of content

For the next 4–6 weeks, choose one manageable stream—say, the blog or campaign landing pages.

Add a very lightweight checklist to the process, such as:

• Headings in logical order
• Descriptive page title and headings
• Alt text for non-decorative images
• Meaningful link text
• Videos with captions or a transcript link

Ask editors to confirm those before publishing. Then compare:

• Issue counts on those pages vs. other pages
• Editorial friction (was it actually unmanageable?)

If issues drop significantly for that stream, you’ve proven that small workflow changes can materially reduce accessibility risk.

---

7. If the problem is workflow: what to change in governance, training, and support

Once you’re convinced the primary issue is content workflow, the fix is not “run another audit.” It’s change how content is owned and shipped.

Here are practical moves that don’t require you to become an accessibility expert.

Clarify who owns accessibility in the content process

Assign explicit ownership such as:

• Content owners – responsible for following accessibility guidelines on their pages.
• A central web or digital lead – responsible for guardrails, patterns, and deciding when to escalate design system issues.
• An accessibility partner or specialist – available for edge cases and periodic checks.

Without this, accessibility is “everyone’s job” and no one’s responsibility.

Build simple, high-impact checklists into everyday tools

You don’t need a separate policy manual no one reads. Instead, bake accessibility checks into existing workflows:

• Add a short checklist to content briefs.
• Include an accessibility tick-box in CMS publishing workflows.
• Provide quick reference guides for alt text, headings, and link text.

Focus on the few behaviors that cause most of your issues, rather than trying to teach the entire WCAG spec.

Train editors on the issues they actually control

Run short, focused sessions for common roles:

• Marketing and content teams – alt text, headings, link text, media embeds.
• Designers – how their handoffs and components impact accessibility.
• Regional or partner teams – how to use your templates without breaking them.

Reinforce these with examples from your own site, not abstract rules.

Set rules for introducing new content types and formats

Decide, in advance, what must be true before a new format goes live:

• Who signs off on accessibility for new templates or components.
• How video, audio, and interactive content will provide accessible alternatives.
• When to engage developers or an external partner for component-level changes.

This is the governance layer that prevents the same issues we covered in why accessibility problems return when content changes faster than review.

Plan for ongoing support rather than one-time cleanup

Accessibility is not a “launch task.” It’s a maintenance and support function, like security or uptime.

Operationally, that might look like:

• Quarterly spot checks on high-value sections.
• A lightweight review whenever new templates or content types are introduced.
• A defined escalation path when editors encounter something they can’t fix.

You can run much of this in-house, but many teams find it easier to anchor it with a recurring relationship with an accessibility-focused partner.

---

8. Where a partner fits: treating accessibility as an editorial capability, not a one-off fix

If your diagnostics point to a workflow-driven problem, your next move is not necessarily “launch a redesign.”

A better move is to treat accessibility as a capability you build into your content operation—with the right mix of:

• Design system review (so the foundation doesn’t fight your editors)
• Editorial workflow design (so people know what “good” looks like)
• Training and periodic checks (so regressions are caught early)

That’s the kind of work we package into our ongoing website accessibility services:

• Reviewing both templates and common workflows so we’re fixing the right layer.
• Helping you set realistic guardrails in your CMS and content process.
• Providing training and check-ins so accessibility doesn’t depend on one internal champion.

If you’re ready to treat accessibility as part of how your website is owned—not just another item on a launch checklist—you can start a more concrete conversation with us via our contact page or by exploring our broader services.

If you’re still in research mode, our accessibility topic hub and the rest of the blog cover related questions, including:

• How routine content updates reintroduce problems
• Why new formats and content types create fresh risks
• What a pragmatic accessibility roadmap looks like for a busy team

Use those to deepen your understanding. Then, when you’re ready to act, make sure you’re solving the right problem: not just your design system, but the content workflow that runs on top of it.