A three-layer accessibility approach is a framework that combines continuous runtime remediation, development-time testing, and expert human services into one system, so that accessibility work happens at every point where problems can occur rather than at just one. Accessibility problems don’t live in one place. Some are baked into templates written years ago. Some appear only when a user interacts with a dynamic component. Some can be detected by a machine scanning markup. Others require a human to evaluate meaning, flow, and usability with real assistive technology.
Why accessibility requires multiple layers
Consider a single common issue: an image without useful alternative text. On a large e-commerce site, this problem might exist in thousands of places. A runtime remediation layer can programmatically address empty alt attributes. But it cannot write accurate, contextually appropriate alt descriptions for images when the provided alt text is inadequate. That requires human judgment, a developer addressing the root cause in the template, and if the site serves a regulated entity, a VPAT document accurately reflecting the current state of conformance.
Three distinct types of work. Three distinct contributors. Three distinct tools or services.
Layer 1: Runtime accessibility
The first layer operates on the live site, in the user’s browser. Tools scan the DOM and apply programmatic corrections to issues they can reliably detect: color contrast, ARIA attributes, form label associations, keyboard navigation, and decorative image markup. The engine runs continuously, adapting as site content changes.
Runtime remediation addresses issues in legacy content and third-party components that development teams can’t quickly fix at source and provides continuous monitoring to catch regressions as updates are made.
Layer 2: Development-time testing
The second layer moves accessibility earlier in the development lifecycle. Developer-facing accessibility testing tools integrate into CI/CD pipelines and development environments, flagging WCAG issues as code is written and before it reaches production.
Issues fixed in code don’t require runtime correction on the live site, and developers build accessibility knowledge by seeing violations flagged in their normal workflow. Development-time tools surface findings to developers; they don’t apply automatic source code fixes. Developers remain in control of how issues are resolved.
Layer 3: Expert services
The third layer is the work that cannot be automated: manual audits, VPAT and ACR documentation, user testing with people who use assistive technology, accessible PDF remediation, and accessibility program management.
Expert services are required for organizations responding to procurement requirements, regulatory mandates, or legal pressure, and they produce the evidence record that courts, procurement offices, and regulators look for.
