Responses in Experiments

Experiments

Testable supports a wide range of response types for experimental trials. Use the buttons column for on-screen buttons, the key column for keyboard responses, or the responseType column for richer response widgets like sliders, text boxes, and drag-and-drop.

Survey question types are covered in Survey Response Types.

Button responses

Create on-screen buttons with custom labels.

Column: buttons Values: button labels separated by semicolons

buttons = Yes; No; Not sure

• You can define up to 12 buttons (button1 through button12)
• Buttons can be used for advancing to the next trial (e.g. for instructions) or to record responses from participants (e.g. “Same”, “Different”, “Next”)
• Testable numbers buttons from left to right starting at 1, so responseCode in results will be 1, 2, or 3 for the example above

Keyboard responses

Enable specific keyboard keys as valid responses.

Column: key Values: key labels separated by spaces

key = f j

• f j will enable the keys F and J
• 1 2 will enable the keys 1 and 2
• Special keys are supported: space, enter, left, right, up, down
• Use all to allow responding with any standard key on the keyboard
• Key combinations and modifier keys are supported: Ctrl+S, Shift+A, Alt+left

Caution

All keys that are not specified will be unresponsive.

If you leave buttons empty and don’t specify key, any key press will advance the trial.

Allowing multiple keyboard inputs

You can define how many keyboard responses are required or allowed in a single trial.

Column: responseOptions (used with key) Values: min:number;max:number

• If min is set, participants must press at least that many valid keys before they can continue
• A button to advance appears only after the minimum is reached
• When the maximum number of presses is reached, the experiment advances automatically

Examples:

• min:2;max:4 requires the participant to press 2 to 4 keys
• max:4 accepts up to 4 key presses; the trial ends when 4 are reached or if the user presses ‘Confirm’

The key column also defines the correct response for accuracy scoring. See Defining correct responses below.

Other response types (responseType)

The responseType column enables richer response modes beyond buttons and keyboard.

Text boxes (box)

Allow participants to type free-text responses.

Column: responseType Value: box or box*number (e.g. box*3 for three text boxes)

• Multiple boxes are centered horizontally below any stimuli by default
• You can have more or fewer boxes than the number of stimuli
• You can position boxes manually using the responsePos column (see Positioning text boxes)

On type = form rows, box renders a survey text input instead; see Survey Response Types.

Positioning text boxes

Use responsePos together with responseType = box*number to control where text boxes appear relative to stimuli.

Column: responsePos Values: below, above, left, right

• Defines the position of the box(es) relative to the stimuli
• Example: responseType = box*2 and responsePos = left;right shows one box to the left of the stimulus and another to the right

Multi-line text area (comment)

A multi-line text area for longer free-text responses.

Column: responseType Value: comment

On type = form rows, comment renders a survey text area instead; see Survey Response Types.

Sliders (slider)

Display a horizontal slider scale. By default, the slider ranges from 0 to 100 with step size 1.

Column: responseType Value: slider

On type = form rows, slider renders as a survey question; see Survey Response Types for the differences (for example, how untouched form sliders are recorded).

Customising sliders

Use the responseOptions column to control slider range, step size, starting position, and appearance.

Column: responseOptions (used with responseType = slider) Syntax: min_max_step;start;flags

Examples:

• 1_50_2;10 gives a slider between 1 and 50 in steps of 2, starting at position 10
• hideGrid hides the grid lines on the slider
• hideStart sets no starting position (participant must move the slider)
• hideValue hides the numeric display of the selected value
• hideMinMax hides the min and max values at the ends of the slider
• removeFill removes the colour fill that highlights the slider up to the selected point

Tip

Sliders also work with text labels. All steps must be defined explicitly: poor_average_good;average creates a slider with three options, starting at average.

Mouse clicks (clicks)

Allow participants to respond by clicking directly on stimuli or the screen. There are three click modes, all requiring responseOptions to be defined.

Column: responseType Value: clicks

Record pixel location

Record the exact pixel coordinates where a participant clicked on an image.

Column: responseOptions Value: pixel

• Records the location of the mouse on the clicked image
• Works for trials with one or multiple images

Tip

Example result: 2_30x40 means the participant clicked on the second image, 30px from the top and 40px from the left (relative to the top-left corner of the image).

Custom origin point

By default, the (x=0, y=0) origin is the top-left corner of the clickable stimulus. You can change this by adding an origin option:

responseOptions value	Origin point
pixel, origin:topLeft	Top-left corner (default)
pixel, origin:topRight	Top-right corner
pixel, origin:bottomLeft	Bottom-left corner
pixel, origin:bottomRight	Bottom-right corner
pixel, origin:center	Centre of the image

Clickable response grid

Overlay an invisible grid on top of images and record which cell was clicked.

Column: responseOptions Value: grid(rows x columns) (e.g. grid(3x4))

• grid(3x4) creates a grid of 3 rows and 4 columns on top of each image displayed on screen
• Records the image and cell that the participant clicked

Tip

Example result: 3_5 means the participant clicked on the 5th cell of the 3rd image. The grid is invisible to the participant.

Minimum and maximum number of clicks

Specify how many times a participant must click before advancing.

Column: responseOptions Value: min:number;max:number (e.g. min:2;max:4)

• min:2;max:4 requires a minimum of 2 clicks and a maximum of 4 clicks to advance
• Participants cannot advance until the minimum number of clicks is reached
• A button to advance appears only after the minimum is reached
• When the maximum is reached, the experiment advances automatically to the next trial (if no buttons are defined), or displays the defined buttons

Assign labels (label)

Allow participants to assign labels to images by drag and drop.

Column: responseType Value: label

Use responseOptions to define the available labels:

Column: responseOptions Value: label names separated by semicolons (e.g. label1; label2; label3)

Tip

The number of labels can be more or fewer than the number of stimuli.

Caution

Only works if your stimuli are images.

Record voice (mic)

Record voice responses from participants via their microphone.

Column: responseType Value: mic

By default, mic works as a voice key: any voice input advances the experiment to the next trial, and nothing is saved. Use responseOptions to keep the audio.

Note

This is separate from session audio recording (Setup → General → Recording → Audio), which records the participant’s microphone across the whole session into one file per participant, regardless of what the trial file does. See General Settings.

Column: responseOptions

Value	Meaning
(empty or na)	Voice key only. Speech onset advances the trial, nothing is saved.
save	Same as save:1000. Saves 1 second of audio from voice onset.
save:MS	Saves audio from voice onset until onset + MS milliseconds, then the trial advances.
save:all	Records everything from the start of the trial until a button or key press, or until the responseWindow deadline ends the trial.
save:no	Explicit way of saying “do not save” (identical to leaving responseOptions empty).
start:trial	Modifier for save and save:MS: recording begins at the start of the trial instead of at voice onset.
preVoice:MS	Modifier for save and save:MS: keep MS milliseconds of audio from just before the detected voice onset, so soft speech beginnings are not cut off. Default 0 (recording starts exactly at the detected onset). Example: preVoice:200.
noHide	For unsaved voice key trials only: the stimulus does not disappear when the voice response is given. Trials that save audio always stay fully visible, so this token is not needed there.
hideRec	Hides the recording indicator (the pulsating dot, mic icon, and countdown).

Combine multiple options with ;, for example responseOptions = save:500;noHide or responseOptions = save:2000;start:trial.

Tip

The default recording duration for a bare save is 1000 ms (1 second). Recordings that start at voice onset begin exactly at the detected onset by default; add preVoice:200 to also keep the 200 ms just before it, so soft speech beginnings are not cut off. Recordings that start at trial start (save:all, or start:trial) capture everything from the beginning and need no preVoice.

Examples

responseType = mic, responseOptions = na                     (voice key, nothing saved)
responseType = mic, responseOptions = save                   (onset to onset + 1s)
responseType = mic, responseOptions = save:2000              (onset to onset + 2s)
responseType = mic, responseOptions = save:2000;start:trial  (trial start to onset + 2s)
responseType = mic, responseOptions = save:all               (everything, until a press or the deadline)

Combining voice with buttons and keyboard

Buttons and keys defined on a mic trial always stay active alongside the microphone.

• With save or save:MS, the voice response and the press race each other. Whichever happens first ends the trial.
• With save:all, voice never ends the trial by itself. Only a button press, a key press, or the responseWindow deadline does.
• A press is always safe. It finalises and saves any recording that is in progress, so audio is never lost. With save:all (or start:trial), a press before any speech still saves everything captured from the trial start. With plain save/save:MS, recording only begins at voice onset, so a press before any speech ends the trial with no audio file (the results columns show na).

Caution

Always pair save:all with a button, a key, or a responseWindow deadline. Without one of these there is nothing that can end the trial, and the participant will be stuck recording.

Mic responses in the results file

Mic trials that save audio add columns to the results file (audioFile, recOnset, voiceOnset, recDuration, voiceDuration, and recDropped when audio was lost); they are documented in Results Reference: Trial Columns. The usual response and RT columns reflect whichever event ended the trial: the voice response, a button or key press, or a timeout.

Audio files are named after their trial row (repeats of the same row are suffixed row5_2.wav, row5_3.wav, so nothing is overwritten), and each participant’s recordings can be downloaded as a zip from the Audio column of the Raw Data table.

How microphone input is detected and timed

1. Testable requests microphone permission at the device’s native sample rate (typically 44.1 kHz or 48 kHz)
2. At the start of each session the participant reads a short passage aloud for 13 seconds, which calibrates an individual detection threshold. A live indicator (too quiet / good / too loud) shows the current level while reading. Calibration succeeds only when at least 3 seconds of actual speech were detected, the speech clearly stands out from the background noise, and the microphone is not distorting; each failure shows a specific message (increase the volume, move somewhere quieter, or lower the volume)
3. During spoken-response trials, incoming audio chunks are analysed in real time. Speech onset is declared when amplitude crosses the calibrated threshold
4. Voice onset latency is computed as tOnset minus tEnable using the browser’s high-resolution monotonic clock, and reported in the micOnset column
5. The microphone is armed and disarmed by responseWindow like any other response modality. A min: minimum window also applies to voice, so an onset during the minimum window is held and completes the trial when the minimum ends, keeping the original onset time as its reaction time

Sort stimuli (sort)

Allow participants to sort visual stimuli by dragging them into an order.

Column: responseType Value: sort

Use responseOptions to specify which stimuli are sortable by their indices:

Column: responseOptions

• Range syntax: 1:3 makes the first three images sortable
• Individual indices: 1;2;3 makes images 1, 2, and 3 sortable

Caution

Only works for images as stimuli.

Drag to target zones (drag)

Allow participants to freely drag and drop all stimuli on screen.

Column: responseType Value: drag

• Usually combined with a background image defined in the background column, so participants drag movable images over a static canvas
• In the results file, drag responses are in the format StimNo_HorizontalxVertical (pixel offset from centre)

Examples:

• 1_359x3 means the 1st stimulus was moved 359 px right and 3 px down from centre
• 2_-290x-4 means the 2nd stimulus was moved 290 px left and 4 px up from centre

Scoring sort-type responses

When using responseType = sort, you can use the key column to automatically score responses. Define the correct order of stimuli names separated by ;.

Scoring uses position distance, the sum of how far each stimulus is from its correct position. 0 is a perfect score.

Example:

stimList = image1; image2; image3
key = image3; image2; image1

• If participant sorts: image3; image2; image1 → correct = 0 (all in correct positions)
• If participant sorts: image3; image1; image2 → correct = 2 (image1 and image2 are each 1 position away)

Tip

With 3 stimuli the worst possible score is 6 (all 3 images are 2 positions away from their target).

responsePos: button and response position

Use responsePos to control where buttons appear on screen:

• bottom (default)
• top
• left
• right
• Custom pixel position using x,y coordinates

Defining correct responses

The key column defines the correct answer for accuracy scoring.

• For button responses: the correct key is the number of the button (e.g. 2) rather than the button label
• For responding by clicking stimuli: the correct key is the position of the stimulus on screen (e.g. 2) or the name of the stimulus column (e.g. stim2)

Multiple correct answers: separate with a semicolon:

key = f; F

Alternative correct responses (OR logic): use | to define responses where any one is scored as correct:

key = 1 | 2 | 3

This means either 1 or 2 or 3 is correct in this trial.

RT-based correct responses: score based on reaction time range rather than the response itself:

key = RT200_300:

The response is scored correct if it was given between 200 and 300 milliseconds.

Tip

When using stimulus order randomisation, use the stimulus column name (e.g. stim2) to define the correct key, as the position of the image will be randomised. Using the column name preserves stimulus identity, regardless of where it appears on screen.

Showing participants their performance

To display the response, reaction time, or accuracy back to participants after a trial (including %response%-style variables and image feedback), see the Feedback page.

Enforcing response formats

Testable allows you to control how participants type in their responses by using HTML5 input attributes via the responseOptions column. This works with responseType = box in test trials.

How response constraints work

Each rule is written as property:value. Combine multiple rules with semicolons:

responseOptions = type:number;min:10;max:99

Available properties

Property	Effect
type	Input type (number, date, color, email, etc.). Some types change the input widget (e.g. type:date shows a calendar picker)
step	Allowed intervals between numbers (e.g. step:5 allows 5, 10, 15…)
min	Minimum numeric value
max	Maximum numeric value
maxlength	Maximum number of characters
placeholder	Greyed-out example text inside the response box
pattern	Regular expression to enforce specific text formats

Combinations are allowed. For example: pattern:[a-z]+;maxlength:10 accepts any lowercase text up to 10 characters.

Advanced input rules with pattern

The pattern property uses regular expressions (regex) to enforce specific response formats:

Rule	Pattern
Text only (letters)	pattern: [A-Za-z]+
Four-digit number	pattern: \d{4}
Date (YYYY-MM-DD)	pattern: \d{4}-\d{2}-\d{2}
Alphanumeric code (ABC123)	pattern: [A-Za-z]{3}\d{3}
Restrict to specific words	pattern: (France|Germany|Italy|Spain)
Numeric range with sum	min:10;max:99;sum:30

Caution

Response format enforcement is only compatible with test trials using box responses.

Next steps

• Timing Parameters: control when responses are enabled and disabled
• Feedback: show participants their performance after each trial
• Survey Response Types: the question types available on form trials
• Forms and Surveys: form row anatomy, pages, and layout