In real-world projects, accessibility rarely breaks because of a lack of technical knowledge.
It breaks because of accumulated design decisions — small compromises that seem harmless at first and become difficult barriers to undo over time.

It's not always an ARIA or roles problem.
Very often, it's design debt.

---

What do we mean by design debt?

Just like technical debt, design debt appears when speed is prioritized over the long-term sustainability of a visual system.

Common symptoms include:

- One-off components “just for this screen”
- Undefined or undocumented states
- Constant visual exceptions
- Decisions driven by short-term aesthetics

Each individual decision might seem reasonable.
The problem shows up when the system grows.

---

When design decisions hurt accessibility

Many accessibility barriers are created before a single line of code is written.

Typical examples:

- Contrast pushed to the limit “because it looks cleaner”
- Components without clear states (hover, focus, disabled)
- Implicit interactions that are never documented
- Over-reliance on color or animation

The code simply enforces a decision that was already broken.

---

Components that don't scale

A component can work well in one context and completely fail when reused elsewhere.

Warning signs:

- The component constantly needs overrides
- Contrast must be adjusted on every use
- Focus is “fixed” case by case
- Accessibility depends on context

That's not flexibility — that's accumulated debt.

---

Design without states equals fragile experiences

One of the most common mistakes is designing only the “ideal” state.

What's usually missing?

- Error states
- Real disabled states
- Loading states
- Empty states

When these states aren't designed, they get improvised during development — and accessibility is usually the first thing to break.

---

Accessibility as a symptom, not the cause

When an audit uncovers many issues, the problem rarely lies in the last commit.

It usually comes from:

- Incomplete visual systems
- Missing shared criteria
- Undocumented decisions
- Design and development working in silos

Accessibility exposes structural problems that were already there.

---

Quick checklist to spot design debt

Before the issue reaches the codebase, ask yourself:

- Are all component states clearly defined?
- Are contrasts defined by role, not just color?
- Is focus part of the visual language?
- Does the component still work without animations?
- Can it scale without manual tweaks?

If any answer is “it depends”, there's debt.

---

How to reduce it (without slowing teams down)

It's not about designing more — it's about designing better:

- Clear, constrained visual systems
- States defined from the start
- Accessibility as a design criterion
- Living documentation, not decorative docs

Accessibility doesn't slow teams down.
Fixing it late does.

---

Conclusion

Many accessibility problems aren't solved with more code, but with better design decisions.

When design is consistent, components scale.
When components scale, accessibility almost takes care of itself.

Design debt stays invisible…
until it starts costing time, money, and users.