Skip to main content :::
:::

How to Monitor Accessibility After Launch

One-time audits cannot cover every later change. Post-launch accessibility monitoring should combine user reports, interaction signals, low-frequency machine scans, and manual review.


Summary

  • Websites keep changing, so accessibility cannot rely on one check.
  • After launch, teams should watch user reports, interaction barriers, and page scan summaries.
  • These signals are not a full audit, but they help teams decide which pages need human review first.

Why one check is not enough

Content updates, campaign pages, third-party embeds, A/B tests, design changes, and component revisions can break flows that used to work. Pre-launch testing matters, but it only represents one point in time.

What signals should be monitored?

Post-launch monitoring should not only watch scores. It should point to concrete pages that deserve review.

  • User reports: what kind of barrier appeared on which page.
  • Repeated clicks: users may think something is actionable or may not receive feedback.
  • Blocked keyboard interaction: focus, keys, or states may not match expectations.
  • Focus U-turns and Escape failures: users may be trapped in a flow or interface.
  • Low-frequency machine scan summaries: whether the page has machine-detectable WCAG A/AA or best-practice risks.

Turn signals into a maintenance rhythm

Pulse does not claim that a site is compliant. Its value is collecting post-launch clues in Console so maintainers can regularly decide which pages need human review. Signal lets users report barriers to Accesserty and lets verified maintainers review reports for their domains in Console.

Related pages