What is Accessibility Sludge and How to Get Rid of It
Nobel Prize-winning behavioral economist Richard Thaler defines “sludge” as unnecessary friction that makes it harder for people to accomplish something. While Thaler applied the term primarily to consumer and government experiences, the same principle also applies to accessibility. Accessibility sludge shows up as delays, roadblocks, and inefficiencies that don’t need to exist. Yet, their existence can significantly hinder accessibility programs. Sludge doesn’t just get in the way; it prevents progress.
Sludge doesn’t always require bad intentions. It often comes from outdated processes, mismatched priorities, and a lack of accountability. No matter where accessibility issues start, the result is the same: accessibility progress stalls, while barriers excluding people with disabilities remain.
Accessibility sludge can even exist in programs that technically do everything correctly. You can have the best auditors, the most robust design system, and comprehensive training. However, if internal sludge continues to grow, your accessibility program will come to a standstill. That’s not a resource issue. That’s a leadership and operations failure.
Approval Loops That Go Nowhere
One of the most common types of sludge is never-ending approval cycles. Accessibility issues that should take a day to fix instead take months because five departments need to weigh in, and none of them are accountable for making the final call. I have yelled at program managers at multiple employers, “I could have coded this in less time than this one meeting took.” Approval sludge looks like this:
Tickets reopened over minor language preferences.
Lengthy and repetitive legal reviews that block progress instead of supporting fixes.
People spending more time preparing slide decks for leadership than actually fixing anything.
This kind of sludge creates burnout. People give up. Issues pile up. Disabled users continue to wait for access that should have been in the system all along.
Pointless Reporting That No One Reads
Reports are essential when they’re used correctly. But when reporting becomes an exercise in spreadsheet performance art, it’s just sludge. Accessibility teams are often buried in metrics that have no connection to real outcomes. They’re asked to log every bug, even if it’s the tenth time the same issue has come up and it’s part of a page template. They’re told to “prove return on investment (ROI)” without being informed what would be considered good enough.
No accessibility program has time to waste building dashboards for leaders who never log in. If your reporting structure creates more work than it solves, it’s sludge. Get rid of it.
Inconsistent Standards
This form of sludge hits hard in organizations that grew quickly or operate in silos. One team codes buttons one way, and another team does it differently. One QA team checks for accessibility using Chrome and NVDA, the other checks for accessibility using macOS and VoiceOver. The result? Duplicative effort, which is pure sludge.
Standardizing components, testing practices, and documentation doesn’t just save time; it also improves efficiency. These tasks are essential to scaling access. Every deviation adds friction. Every inconsistency invites regressions. If you don’t have a shared understanding of what “accessible” means, you're going to stay stuck in cleanup mode forever.
"Accessibility by Exception" Mindsets
When accessibility becomes something teams need to “ask for permission” to do, that’s sludge. Accessibility isn’t an exception. It’s a requirement. Yet, many programs are still stuck in cultures where teams have to justify every accessibility decision, from adding alt text to running a manual audit. They’re told to wait until after a release to address accessibility issues because the product team doesn’t think accessibility matters during beta testing.
“Accessibility by Exception” mindsets reinforce exclusion. Every delay adds to technical debt. Every “we’ll get to it later” puts up a new wall. Accessibility has to be built into the roadmap to avoid sludge.
Overly Complex Tooling
Tooling is supposed to help technical initiatives. But when accessibility teams have to jump through three platforms, two permissions models, and a labyrinth of authentication systems to log a bug, possibly in an inaccessible tool, something has gone very wrong. Tooling sludge slows down every part of the program. It keeps new hires from ramping up. It causes issues to get lost or mislabeled. It wastes time and kills momentum.
If your accessibility work can’t be done quickly and clearly with the toolset you have, the tools are the problem.
Don’t succumb to the sunk cost fallacy. The cost of the sludge may far exceed the amount you have invested in your tooling.
Simplify your processes. One minute lost per operation in a team of 8 logging 30 bugs per day each is 20 hours of lost time.
Integrate your systems. Log bugs with a single button press from the test results.
Use a consistent tagging system to reduce the number of places people have to look.
Hiring Without Clear Ownership
You can’t run an accessibility program with 10 percent of someone’s time. You can’t expect results from a group of volunteers who meet once a month. Accessibility issues thrive in organizations that lack clear roles, dedicated ownership, or a seat at the decision-making table. Without leadership, priorities shift, budgets disappear, and progress evaporates.
Successful accessibility efforts require dedicated personnel, measurable goals, and individuals with the authority to say yes, not just those who know how to say “no” to risk.
Budgeting Blockers Are Sludge, Too
One of the most toxic and persistent forms of organizational sludge is the approach to accessibility budgets. Every accessibility lead has heard the same excuses: “We didn’t budget for that this year.” “Can you wait until next quarter?” “Let’s hold off until legal weighs in.”
But then, without warning, money becomes magically available a split-second after a legal threat appears. A lawsuit or demand letter arrives, and suddenly, the same leaders who claimed there were no funds can approve six-figure settlement agreements and rush to hire high-priced external consultants. Internal teams weren’t given the resources to prevent the problem, but there’s always money to respond to it.
This kind of reactive budgeting is sludge in its purest form. It wastes time. It costs more. It produces an inferior result. It annoys stakeholders who are pulled off of what they want to do to “fix those pesky accessibility programs.” But most importantly, budgeting sludge puts the burden of inaccessibility on disabled people until the threat of legal consequences forces change. You don’t need a court case to justify budgeting for accessibility. You need accountability.
Proactive accessibility isn’t free, but it’s always cheaper than cleaning up a legal mess. And more importantly, it centers inclusion instead of liability. If your first accessibility budget line is for legal fees, priorities need to be reexamined.
How to Remove Accessibility Sludge
Removing accessibility sludge requires serious cleaning. That means:
Streamlining approvals and cutting out review loops that don’t add value
Replacing performative reporting with actionable, transparent data
Creating a single source of truth for standards and enforcing it across all teams
Don’t require an ROI before making things accessible
Making sure your tools support the work rather than slow it down
Hiring dedicated staff and giving them the resources to lead
Allocating budgets proactively, not just when you’re in legal trouble
You can’t build inclusion on top of inefficiency. Sludge might not be visible to your users, but its impact is. If your accessibility program moves slowly, inconsistently, or only in response to lawsuits, it’s likely bogged down in sludge.
Accessibility isn’t just about what the user sees. It’s about how the work gets done. If you want lasting progress, you need to identify and remove the sludge inside your program. Otherwise, the barriers you’re trying to break down will keep rebuilding themselves — one approval, one delay, one inaccessible PowerPoint deck at a time.