Skip to content

Interaction scenarios

Automated scans normally see only a page’s initial render. Many real accessibility failures live behind an interaction: the focus-trapped dialog, the unlabeled links in a collapsed menu, the error messages a form shows on submit. Interaction scenarios let a scan perform a short list of safe actions and re-check the page in the resulting state.

Available on Growth plans and above. Configure them per site under Site settings; owners and admins can edit.

  1. The page scans normally first: the usual axe pass, probes, and screenshot all run against the untouched page, and the compliance score is calculated from that baseline exactly as before.
  2. Each scenario then runs on a fresh load of the page: the scanner performs its actions, re-runs axe, and keeps only the violations that were not present in the baseline.
  3. Those new violations become normal issues tagged with the scenario (“Found after interaction: Open nav menu”), so they get the full workflow: assignment, comments, Jira/Linear sync, and automatic resolution once the scenario stops reproducing them.

Scenario findings never change the compliance score. The score stays an initial-render measurement; scenarios widen what the issue queue can see.

A scenario is a name plus an ordered list of actions:

ActionWhat it does
ClickClicks the element matching a CSS selector
FillTypes text into an input
Press keySends one navigation key (Tab, Escape, Enter, arrows)
HoverHovers an element
Wait for elementWaits until a selector is visible or hidden
Wait (ms)Pauses up to 5 seconds

A typical “open the nav menu” scenario is two actions: click button.nav-toggle, then wait for nav[aria-expanded="true"] to become visible. The optional URL pattern (a glob like /checkout/**) restricts which pages run the scenario; leave it empty to run on every scanned page.

  • Up to 10 scenarios per site and 15 actions per scenario; each action gets 5 seconds and each scenario about 20.
  • Scenarios are declarative: there is no way to run scripts, and an action that navigates away from the page ends the scenario.
  • A failing scenario is recorded as skipped and never fails the page scan; the per-scenario outcome is stored with the scan for debugging.
  • Fill values are stored in plain text with your scan settings, so never put passwords or API keys in them. For pages behind a login, use Authenticated scanning, which encrypts credentials.

Scenario-tagged issues cannot be checked by the quick single-page verify (it scans the initial render, which never shows the problem). Run a normal site scan instead: when the scenario stops reproducing the violation, the issue resolves through the usual “no longer found” flow.