Skip to content
AbilityBench

Action cancellation

Stop signal task with an SSRT estimate you can check

Answer which way each arrow points, and on a quarter of the trials a white bar drops across it shortly afterwards and you have to cancel the keypress you had already started — 128 trials in about four minutes. The delay before the bar is walked by a staircase until you fail about half the stop trials, the one condition under which stopping latency can be estimated. That latency, SSRT, is never observed, so the page prints every input that produced it.

  • 128 trials, 32 with a stop signal
  • 50 ms staircase

128 arrows, about four minutes with two breaks. Answer the side each one points as fast as you can; on 32 of them a white bar drops across the arrow shortly after it appears, and on those you must not finish the keypress you had already begun. The bar comes late enough that you will fail roughly half of them — that is the design working, not you failing.

The procedure, in full

Go task
an arrow pointing left or right, half of each, drawn in one pale gray
Keys
F for left and J for right, read by physical position so the layout does not matter
Stop signal
a white frame and a white bar across the arrow on 32 of the 128 trials — luminance and shape, no hue
Delay
starts at 200 ms and moves 50 ms after every stop trial: later when you stop, earlier when you do not
Window
1250 ms from the arrow appearing, then the trial closes
Void
answered inside 150 ms, answered before the arrow appeared, or interrupted by this tab losing its frames
Order
runs of the same trial type capped at 6 and runs of the same side at 4

Do not hold back for the bar. Waiting makes stopping easy, the delay lengthens to compensate, and the estimate ends up describing a strategy instead of a brake — so the run checks afterwards whether your speed drifted and reports what it found.

The practice trials hold the bar at a fixed 200 ms and say what happened after each one. They feed nothing: the tracked delay begins at 200 ms when the scored run does.

Why stopping time has to be estimated

A successful stop produces nothing to time. On every other timed task the thing measured ends in a keypress with a timestamp on it; here success is the absence of a response. What can be observed is how often the response escapes at a given delay, and the later the bar comes, the more often going wins. The estimate reads stopping latency out of that relationship using a horse race — Logan & Cowan (1984), On the ability to inhibit thought and action: A theory of an act of control, Psychological Review: going starts when the arrow appears, stopping starts when the bar appears, and whichever finishes first decides the trial.

At the delay where you press exactly half the time, the stopping process must finish where half of your go responses fall. So the delay moves 50 ms later after every successful stop and 50 ms earlier after every miss — from 200 ms, between 0 and 800 ms — which settles on 50% by construction. Your go times are ranked, choice errors included, the time at the rank matching your response rate on stop trials is read off, and the mean delay is subtracted. Published estimates fall in 150-250 ms (Verbruggen et al. (2019), A consensus guide to capturing the ability to inhibit actions and impulsive behaviors in the stop-signal task, eLife); that is a span across studies rather than a distribution, so your figure is placed beside it and never converted into a rank.

Four ways this estimate goes wrong

  • Waiting for the bar. Answering more slowly than you naturally would makes stopping easy, the staircase answers by pushing the delay later, and the number ends up describing your patience. The run compares your go speed in the first and last quarters and prints the drift.
  • A violated race. The responses that escape the bar must be your quicker ones. If the mean time on failed stops comes out above your ordinary go time, going and stopping were not independent and the arithmetic does not apply — the run checks and says so.
  • A drifted rate. The response rate on stop trials is printed with a Wilson interval, so you can see whether half is even inside it.
  • A short run. Thirty-two stop trials is fewer than the consensus guide asks for, and nothing on the page can fix that; the spread of the staircase reversals printed beside the estimate shows what it cost.

The same executive machinery measured through rule-switching instead of cancellation is the Wisconsin card sorting test, and through planning, the Tower of London test.

A reaction time here is the interval between the frame that painted the stimulus and the timestamp the browser attached to your key, both read from the same monotonic clock. What neither can see is the display pipeline behind it, so on a 60 Hz screen roughly 16 ms of every figure below is the machine rather than you. That is the timing floor: two numbers closer together than that are the same number, and this page reports no precision it cannot support.

The bar is drawn on the first frame at or after the requested delay and that paint is timestamped, so the delay used in the subtraction is the one that happened — on a 60 Hz panel it runs about a frame later than requested, and the result reports the median offset it measured.

This is a measurement exercise, not a clinical assessment. It reports what you did on this page against a stated reference and nothing more — it cannot establish ADHD, an impulse-control disorder or any other clinical condition. Only a qualified professional, working with more than a browser, can make that judgment.

Before you run it

Can I not just wait for the bar and stop every time?

You can, and it destroys the estimate rather than improving it. Holding back lengthens your go times, which makes stopping easy, which makes the staircase push the delay later — the loop is stable and the number at the end describes a strategy. Answer at your normal speed with your index fingers on F and J, and let about half the stops fail; that is the run working, not you failing.

Why is the stop signal something you see rather than something you hear?

Because a tone this page cannot verify you heard would be recorded as a failure to inhibit. In a laboratory the volume and the headphones are known; in a browser the output may be a laptop speaker in a noisy room, and a missed tone and a failed brake produce the same data. A white bar drawn over the arrow is on the screen you are already watching, carried by brightness and shape rather than color, and its onset can be timestamped to the frame.