To monitor website accessibility issues, set up recurring automated scans across key pages, log results in a tracking platform, and review changes on a fixed cadence. Scans only flag approximately 25% of issues, so monitoring catches regressions on the items machines can detect: missing alt text, color contrast drops, broken ARIA references, form label issues, and heading order problems. The goal of monitoring is not WCAG conformance. That requires a (manual) audit. The goal is early detection so small issues do not pile up between audits.
Accessibility Tracker Platform was built for this exact workflow: continuous scanning, issue tracking, and a clean record of what changed and when.
| Element | What It Covers |
|---|---|
| Purpose | Detect regressions and new issues between audits |
| Method | Automated scans on a recurring schedule |
| Coverage | Approximately 25% of WCAG issues (machine-detectable only) |
| Cadence | Weekly or monthly for active sites, daily for high-change pages |
| Output | Issue list, change history, page-level reports |
| Not a Substitute For | A (manual) accessibility audit or user evaluation |
What Monitoring Actually Detects
Automated scans review your HTML, CSS, and rendered DOM for issues that follow predictable patterns. They are accurate on the items they cover and silent on the rest.
Common detections include: images missing alt attributes, form inputs without associated labels, color contrast below WCAG 2.1 AA thresholds, empty buttons and links, invalid or broken ARIA references, document language not declared, duplicate IDs, and heading order skips.
What scans cannot detect: keyboard traps in custom components, focus management in modals, meaningful alt text quality, accurate name and role for custom widgets, reading order issues, video captions accuracy, and any content judgment. Those require human review.
How Often Should You Monitor?
Cadence depends on how often the site changes.
For a marketing website with monthly content updates, weekly scans are enough. For an ecommerce store pushing product changes daily, daily scans on the templates that drive the most traffic make sense. For a SaaS web app with continuous deploys, scans tied to staging and production builds are the cleanest path.
The principle is the same across cases: scan often enough to catch regressions before they reach a meaningful number of users.
Setting Up a Monitoring Workflow
A working monitoring setup has five parts.
First, define the pages or templates to scan. You do not need every URL. You need the templates that represent your site: homepage, product page, category page, cart, checkout, account, blog post, contact. Coverage of templates equals coverage of the site.
Second, set the schedule. Pick weekly or monthly based on change velocity. Lock the schedule so it runs without intervention.
Third, route results into one place. Scattered scan reports across tools create noise. A single tracking surface keeps the record clean.
Fourth, assign ownership. Issues need a name attached. Without ownership, scan results lose freshness in a tab nobody opens.
Fifth, review on a cadence. Even a 15-minute weekly review keeps the queue current.
Where Accessibility Tracker Fits
Accessibility Tracker Platform brings scanning and issue tracking into one place. The scan and monitoring feature inside the platform runs on the pages you select, surfaces issues with severity context, and keeps a running history of what was detected on each pass.
Issues from scans live next to issues from audits. That matters because the two streams need different treatment. Audit issues map to specific WCAG success criteria with auditor notes. Scan issues flag patterns that may or may not be true issues until reviewed. Keeping both in one platform means decision-makers see the full picture without stitching reports together.
What Monitoring Cannot Replace
Monitoring is a maintenance layer, not a conformance layer. A (manual) accessibility audit is the only way to determine WCAG conformance because the majority of success criteria require human judgment.
If a vendor or buyer asks for evidence of WCAG 2.1 AA conformance, scan reports do not answer the question. An audit report and, where applicable, an ACR do.
Use monitoring to keep the site clean between audits. Use audits to establish where the site actually stands.
FAQ
Is monitoring enough to make a website ADA compliant?
No. Monitoring catches a portion of issues that scans can detect. ADA compliance for a website is anchored in WCAG conformance, which requires a (manual) audit. Monitoring supports the work between audits but does not replace it.
How is monitoring different from a one-time scan?
A one-time scan gives you a snapshot. Monitoring gives you a trend line. The value of monitoring is detecting when something changes: a new component ships without labels, a redesign drops contrast, a third-party script injects inaccessible markup. A snapshot misses all of that the moment it ends.
Can I monitor a staging environment before launch?
Yes, and it is a good practice. Catching issues in staging is faster and cheaper than catching them in production. Set up scans on staging URLs and route results to the same tracking surface your production scans use.
What should I do when a scan flags a new issue?
Confirm it is a real issue, not a false positive. Assign it to the owner of that component or page. Track the fix to closure. If the issue affects a pattern used across many pages, address the pattern once rather than each instance.
Monitoring is the quiet work that keeps an accessibility program honest between audits. Done consistently, it shortens the distance between an issue being introduced and an issue being fixed.
Start monitoring with Accessibility Tracker: Contact the Accessibility Tracker team.