A company launches a redesigned website in January. The team runs an automated scan. A few issues are flagged and fixed. Someone signs off on it. Accessibility is checked off the list.
By March, the marketing team has published twelve new campaign pages. The content team has added forty blog posts. None of this went through an accessibility review.
In December, the company commissions its annual accessibility audit. The report comes back. One hundred and seventy-four WCAG failures across the site. Missing alt text, broken keyboard navigation, poor colour contrast on the new homepage banner, and more.
A backlog is created. Some fixes land before the next quarter. Most do not.
The following January, the cycle repeats. All this happened because of a simple reason. An absence of continuous accessibility monitoring.
The Annual Digital Accessibility Audit Trap
This is the audit trap. The audit finds problems. The problems get documented and few get fixed.
But the audit does not prevent new problems from being introduced between reviews.
According to WebAIM Million’s 2026 report on the accessibility 95.9% of home pages have detectable WCAG failure. In 2024, this percentage was 94.8.
An audit shows you what something looked like at a specific moment. But digital products change constantly. New content is published. Features are updated. Each of those changes can introduce new barriers which happen between audits.
The result is a gradual erosion of compliance. The term ‘accessibility drift’ is used for this phenomenon. It accumulates when no one is watching. It is caused by the absence of continuous accessibility monitoring.
| What an Audit Does | What an Audit Cannot Do |
|---|---|
| Provides a point-in-time snapshot of issues | Prevent new issues from appearing after the audit |
| Identifies failures against WCAG criteria | Monitor changes made between audit cycles |
| Produces a list of things to fix | Ensure fixes are implemented or maintained |
| Satisfies a periodic compliance requirement | Protect against legal risk that arises daily |
| Gives leadership a compliance report | Embed accessibility into day-to-day delivery |
Why Organisations Get Stuck in the Audit Trap
Understanding why audits fail to drive sustained improvement helps break the cycle. Several structural problems reinforce the trap.
Scope Is Often Wrong
A well-conducted accessibility audit starts with careful scoping. Which pages, user journeys, and components matter most? Which parts of the product carry the highest risk?
In practice, scope is frequently decided too quickly and without enough context. Auditors may test pages that are rarely visited. They can miss the checkout flow that thousands of users navigate every day.
For large digital estates, this is not a minor issue. An incorrect scope wastes budget. It produces findings that do not reflect real user impact.
Timing compounds the problem. If an audit is commissioned just before a major release, the product being tested may be very different from the one that goes live a week later.
Depending Too Much on Automated Scanning
Automated tools are fast and scalable. But they are also limited. Automated testing can detect up to 57% of accessibility issues by volume. But this figure varies depending on the product and test method.
The remaining issues, such as logical reading order, meaningful link names, and confusing keyboard interactions, require a human to evaluate them. Many organisations stop at the automated scan. They receive a score, declare success, and move on.
A score of 100 on an automated accessibility checker does not mean a page is accessible. It means no automatically detectable issues were found. The distinction is significant.
Reports Without Remediation Guidance
- What is broken
- Why it matters
- How serious it is
- How to fix it.
When reports lack practical remediation steps, they get forgotten. Teams cannot prioritise what they cannot evaluate.
This is especially acute in mobile auditing. When auditors lack access to source code, they can only describe the symptom, not the fix. The gap between finding and resolution widens.
Re-Testing Misses Accumulated Change
Many organisations commission a re-test only on the specific issues identified in the previous audit. This sounds efficient. In reality, it misses everything that has changed in between.
A product that has shipped several sprints of new features since the original audit may have introduced entirely new barriers. In most cases, they fall outside the re-test scope. The re-test passes, but the product still fails real users.
Accountability Is Unclear
Between audits, no single person or team is responsible for maintaining accessibility. Development optimises for delivery speed. Content teams optimise for publication volume. Marketing optimises for campaign launch dates.
Accessibility is not anyone’s job until the auditors arrive. Then for a short period, it becomes everybody’s job. When the auditors leave, it again becomes the responsibility of no one.
Continuous accessibility monitoring solves this by making accountability visible and ongoing.
Moving Beyond Audit Results into Continuous Accessibility Monitoring
Continuous accessibility monitoring is a set of practices that, when embedded together, make accessibility a permanent quality standard. No longer is it a periodic exercise.
The eight steps below close the gap of the annual audit exercise.
a. Build Accessibility into the Process from Day One
The most expensive time to fix an accessibility problem is after a product is live. Retrofitting can cost 10 to 30 times more than building correctly from the start.
Shift left means introducing accessibility requirements at the earliest stage of a project. This starts with a clear policy. Every project, regardless of size, should have explicit accessibility acceptance criteria before design begins.
Define your standard early.
- WCAG 2.2 Level AA is the current international benchmark.
- Section 508 applies to US government and federally funded organisations.
- EN 301 549 covers the EU.
Know which applies to your context and make it a project requirement.
A Shift-Left Approach to Accessibility
- Include WCAG 2.2 AA criteria in project requirements documentation
- Define accessibility acceptance criteria for every user story
- Assign a named accessibility reviewer for each sprint
- Set accessibility as a release blocker, not a post-launch task
b. Create Designs That Prioritise Accessibility
- Check colour contrast ratios at the design stage. WCAG 2.2 requires 4.5:1 for body text and 3:1 for large text and UI components.
- Design for keyboard and touch from the start. Every interactive element should have a clear, visible focus state.
- Include accessible alternatives in your design system. Alt text conventions, caption templates, and error message patterns should be standard components. Do not treat them as additions.
- Design error states and empty states with assistive technology in mind. Screen readers encounter these states too.
c. Use Automated Tools to Check Accessibility
Automated scanning is the foundation of continuous accessibility monitoring. It cannot replace human testing. But it provides consistent detection that no manual process can match at volume.
When selecting an automated scanning solution, prioritise tools that run on a schedule. A scan that only runs when someone remembers to run it is not continuous monitoring.
A11yNow by BarrierBreak
A11yNow is a continuous accessibility compliance platform designed for organisations that need to manage accessibility at scale. It brings automated scanning and structured issue management into a single workflow.
Its rulesets cover WCAG 2.0, 2.1, and 2.2, Section 508, EN 301 549, the European Accessibility Act, and India's RPWD Act. These are kept current. Thus, scan results reflect live regulatory requirements, not outdated criteria.
A standout feature is the scan comparison. Teams can view results side by side across time periods. This makes accessibility improvement measurable and reportable.
At the Enterprise tier, A11yAssist adds AI-generated code fix suggestions. When a scan flags an issue, A11yAssist surfaces a likely fix in context. This reduces the specialist knowledge required for routine remediation. It also quickens resolution.
d. Integrate Accessibility Checks into Your CI/CD Workflow
Automated scanning after a product is live is useful. Automated scanning before code is merged is game changing.
When accessibility tests run as part of your continuous integration pipeline, failures block deployment until resolved. Developers receive immediate feedback when they can act on it most cheaply.
Integrate accessibility linting into your build pipeline. Tools like ESLint with accessibility plugins, or BarrierBreak's A11yInspect ESLint Plugin, flag issues at the code level before they reach QA. This is shift-left in practice.
Define pass/fail thresholds for accessibility in your CI/CD configuration. Treat accessibility failures the same way you treat failing unit tests. The build does not ship until they are resolved.
e. Test with Diverse Users for Real-World Accessibility
No automated tool can tell you whether a form makes sense to a screen reader user navigating it for the first time. This is just one of the many examples.
- Include people with a range of disabilities. This includes people with visual, auditory, motor, and cognitive.
- Test with the assistive technologies your users actually use. Examples are JAWS, NVDA, VoiceOver, TalkBack, and Dragon NaturallySpeaking.
- Conduct testing with users early in the development cycle, not only at the end.
- Document findings in a structured format that developers can act on.
A11yNow gives teams on-demand access to BarrierBreak's accessibility specialists and native screen reader users. These are testers who rely on assistive technology in their daily lives. They validate scan findings and surface contextual barriers that automated tools cannot detect.
f. Equip Your Team with Accessibility Knowledge
Tools and processes can only do so much. Sustainable continuous accessibility monitoring depends on teams that make it part of their daily decisions.
| Role | Core Accessibility Knowledge They Need |
|---|---|
| Designers | Colour contrast, focus states, touch target sizes, cognitive load, error state design |
| Frontend developers | Semantic HTML, ARIA usage and misuse, keyboard navigation, skip links, focus management |
| Content authors | Alt text, plain language, heading hierarchy, descriptive link text, caption standards |
| QA testers | How to test with a screen reader, keyboard-only navigation, assistive technology compatibility |
| Product managers | WCAG criteria, how to write accessible user stories, accessibility acceptance criteria |
| Leadership | Legal obligations (ADA, EAA, Section 508), business case, risk exposure, compliance reporting |
Accessibility knowledge is not just for specialists. Every role in a digital team makes decisions that affect accessibility.
Training should be role-specific. Match the content to the decisions each role actually makes.
Build accessibility into onboarding. A developer who learns accessibility standards from their first week treats it as a baseline. This mindset is the foundation of sustainable continuous accessibility monitoring.
g. Implement a Consistent Accessibility Review Framework
Ad hoc accessibility reviews produce ad hoc results. A consistent framework ensures that accessibility is evaluated the same way, every time, across every team.
- Which standard and conformance level applies? (e.g., WCAG 2.2 Level AA)
- Which pages, components, or user journeys are in scope for each review?
- Who is responsible for conducting each type of review?
- How are findings documented, prioritised, and tracked to resolution?
- What does a pass look like? What triggers a block?
- How often does monitoring occur between formal reviews?
Best Practices for Accessibility Review Frequency
- Continuous: Automated scanning across the full digital estate
- Per sprint: Accessibility review of all new and changed components
- Per release: Full keyboard and screen reader walkthrough of changed journeys
- Quarterly: Expert manual review of highest-traffic pages
- Annually: Comprehensive WCAG conformance audit with VPAT/ACR update
h. Continuously Refine and Enhance Accessibility
Continuous accessibility monitoring is a practice that teams should maintain and improve.
Digital products evolve. Accessibility standards evolve. Assistive technologies evolve. What was acceptable under WCAG 2.1 may need revisiting under WCAG 2.2.
- Use scan trend data to identify recurring issue categories. If contrast failures keep appearing in new pages, that is a design system problem, not a page-by-page problem.
- Monitor user feedback channels for accessibility complaints. Users who tell you something is broken are giving you valuable, specific signal.
- Track resolution time by issue type and team. Slow resolution on certain issue categories often points to a knowledge gap or a process bottleneck.
- Review your VPAT or ACR at least annually. Update it to reflect the current state of conformance honestly.
- Stay ahead of regulatory change. Organisations that monitor the regulatory landscape can adapt proactively.
Conclusion
The annual audit is simply insufficient today.
A one-time review cannot keep pace with a digital product that changes every week. It cannot protect you from the legal risks that accumulate between review cycles.
Continuous accessibility monitoring closes those gaps. It makes compliance visible, accountable, and measurable every day.