Accessibility isn’t a one-time project as much as it's an ongoing process. Blend's Corey Vilhauer talks about where accessibility debt tends to build up — in content, design, and shifting standards — and what you can do to keep it down.
At Blend, we see a lot of different sites. We see well-maintained sites backed by a team of dozens, and we see long-neglected sites propped up by a single overworked champion. We see sites built in the mid 2010s and we see sites that are being redesigned after only a year or two.
In all of these situations, we want to improve the site for accessibility — to bring it into the modern web, where the real humans who visit get an experience that works for them. Accessible, well-structured content helps the crawlers and AI tools that parse our sites, too, but that's a bonus. The people come first. And in all of these situations, we encounter varying levels of debt.
Accessibility debt is the accumulation of accessibility issues due to a lack of attention, lack of resources, or general apathy. It's easy to miss because the people it affects usually don't file a complaint — they just leave. By the time it surfaces, it's either a legal problem or a redesign-sized one.
Some accessibility debt is due to humans, and some is due to policy shifts. But no matter what, accessibility debt peaks when accessibility is treated as a project rather than a process. Let's dive into the kinds of accessibility debt we most often see, and how to begin to address it in each situation.
Debt from content editors.
Content editors — the people who write and publish content on the site — are the most common source of day-to-day accessibility debt. This isn't a knock against editors; the reality of writing, building, and publishing new pages (and updating existing ones) is that accessibility review is just one of dozens of things an editor runs through before something goes live.
Where it shows up:
- Alternative text is either left blank as new images are uploaded, or auto-filled with the file name like "graphic-geo-updates.jpg."
- Links use lazy non-inclusive text like "Read More" or "Click Here," leading screen readers or users tabbing through using the keyboard to encounter links without context.
- Headings are picked for how big they look, not based on page structure, leading to skipped heading levels.
- PDFs are uploaded without confirming they are fully accessible.
- Videos and podcasts are published without captions or transcripts.
- Text styles like underlining or bolding are used to carry meaning, making that emphasis difficult to parse for non-sighted users.
This debt is best handled through editorial training and governance. Hold editors accountable for content accessibility and make sure someone is ready to review each page before or directly after it is published.
Debt from design and development.
When we add new features to our sites — new page types, or new blocks, or especially new custom functionality — we often approach the process through the eyes of the “best possible outcome.” We know these new items are meant to solve a problem, and our focus is on solving that problem. That problem, specifically.
I call this out because that problem is not always every problem, and that’s where accessibility debt most often rears its head. When a new block gets added to the design system, for example, accessibility is often an afterthought — not because it’s ignored, but because the nature of the issue is not often accessibility itself.
So what we often see is a new design element that is perfectly designed to solve a problem, with accessibility as a kind of quick check at the end, if at all. Or, we see design elements or functionality repurposed or re-used without, for example, confirmation that ARIA markup has been adapted or a focus state is still in the right order.
Where it shows up:
- New blocks are added to the design system without keyboard or screen-reader testing.
- Focus states are removed in a redesign because they "looked off."
- ARIA markup becomes stale, either because an element has moved or a component no longer exists.
- Design-first features like modals, carousels, and accordions are added without accessibility considerations.
This debt falls on two things: expectations of the development team, and the process itself. As with editorial governance, the design and development process — and the people therein — must be accountable for new accessibility needs as elements are added or changed.
Debt as a result of new guidelines.
The previous accessibility issues focused mostly on the things we do to the site — like adding content, adding design, or adding features. But debt also accrues when we do nothing at all, because the ground underneath the site keeps shifting.
Take a site built in 2019 to WCAG 2.1. That was the right target at the time. WCAG 2.2 has since arrived as the current version — it added nine new success criteria in 2023 — and WCAG 3.0 is in early development, though it's years from being a standard anyone has to meet. The newer guidelines don't retroactively break a 2.1 site; each version is backward compatible and additive. What they do is add new ground to check against, especially any time you're updating the site.
The legal picture moves on its own schedule. In the US, regulators still point to WCAG 2.1 Level AA — or, at least, that's what the 2024 ADA Title II rule requires of state and local governments and public universities, with quickly approaching compliance dates in 2027 and 2028. Most private organizations fall under different expectations — there's no web-specific federal rule for them, though accessibility complaints are commonly measured against 2.1 AA anyway.
In other words, saying "we were compliant when we launched" won’t stand the test of time.
Where it shows up:
- A newer version of WCAG arrives with new criteria.
- Legal and regulatory expectations within your organization or industry have reassessed what compliance means.
- Screen readers and browsers have updated, causing some markup to be non-compliant.
- New forms of assistive tech pushes at the edge cases of what you’ve already adopted.
Debt caused by the system itself.
Finally, let's look at one of the most frustrating sources of accessibility debt: the system itself. This is a true "blame the tool" situation — your team desperately wants to make accessibility changes, but the CMS or digital asset manager simply isn't set up for progress.
Maybe you want to add alternative text to your images, but images don't have an alternative text field. Maybe you want to create accessible charts but your organization mandates non-accessible embeds. No amount of editorial pushback can change this: you need a new tool, or you need a drastic reimagining of the current one.
Where it shows up:
- The current content model does not include an alternative text field — maybe not even a caption field.
- Blocks are built with auto-generated button or link text that can't be changed by an editor.
- Headings aren't built into the rich-text editor in a way that ensures proper page structure.
Keeping the debt down.
An individual instance of accessibility debt is not a cause for alarm. Things like a blank alt text field or an untested block are small and easily remedied. But that's how this debt begins to snowball — because each individual issue can be so small, it doesn't arrive all at once. The accumulation is where we find ourselves hurting.
Which is to say: the fix isn't a redesign or total overhaul. The fix is process. What keeps accessibility debt low is building the checks into our day-to-day work: editorial review, development checks, constant review of the content model, and (more than anything!) an owner.
Accessibility stays manageable when it stays part of the work. That's harder than a one-time cleanup, and (unfortunately) a lot less satisfying because the work never produces a finished checkmark. But it's how accessibility works — and it's a lot cheaper than paying the debt back all at once.
