Accessibility remediation is software engineering, not a checklist

An accessibility audit is a vital tool, highlighting issues that may otherwise go unnoticed and providing a structured view of a product's accessibility. However, an audit report is not a complete remediation plan. It may seem tempting to treat the findings as the job, working through the list and closing each issue before shipping.

Yet, a finding only reveals what went wrong in the rendered experience. It doesn't necessarily explain why it happened, where it should be fixed, or how to prevent it from recurring. This is when accessibility remediation transforms into software engineering.

A finding represents a symptom rather than a specific location. An audit can inform you of what is wrong with the output but doesn't indicate where in the system the fix should be applied. If the same failure appears on multiple pages, addressing each page individually might fix the reported instances without tackling the root cause.

The more insightful question is where the failure is generated. It could be a shared component, a template, a design-system primitive, the content itself, or a third-party script. The correct solution often involves modifying the structure, not merely adjusting an attribute.

The challenge lies in treating each finding as an isolated task without considering what caused it and whether the fix will endure. Fixing only the output will likely lead to the issue resurfacing when that output is generated again. Fixing the underlying cause ensures the fix is more likely to remain effective despite future changes.

Remediation also carries its share of technical debt. There's always a quicker path - a line of JavaScript that rewrites the DOM after rendering, a one-off ARIA patch, or a duplicated component variant that's accessible. While each can close a finding, they can also degrade the codebase - for instance, a script maintaining server-rendered markup indefinitely, conflicting ARIA, or a fix that breaks when the underlying markup changes.

While these approaches may sometimes be appropriate given the system's constraints, they should be deliberate engineering decisions. The remediation should enhance the code, not merely relocate the problem to a less visible area.

Regression is an intrinsic part of the problem. A fix applied solely to the output is susceptible to regression when that output is regenerated. If a component, template, or design system is reused in a new context, onboarded to a developer who overlooks its issues, or updated upstream, the fix may become obsolete. Implementing the fix directly into the system makes it more resilient.

When correctness is embedded in the component, template, design system, or development process, it doesn't need to be re-decided each time the same pattern is used. This distinction between fixing an instance and fixing the system that produced it underscores the difference between fixing a symptom and resolving the root cause.