# Capture accessibility test evidence

Canonical: https://fairleadhq.com/docs/recorder/accessibility-evidence/

Updated: 2026-10-10
Publication state: published
Product version: Recorder source f6ed5b96

Agent summary: Choose Test case or Explore, capture keyboard and control evidence, separate manual observations, and preserve a scoped accessibility result.

## Prerequisites

- Recorder installed; a defined manual accessibility check

## Inputs

- Expected behavior and relevant assistive-technology context

## Outputs

- A scoped finding with supporting evidence

## Limitations

- No accessibility scanner or focus-path overlay; recorded keyboard events are not a complete focus history

## Permissions

- Authorization to test the application

## Privacy

- Review evidence before sharing


A recommended blueprint for capturing keyboard and visual evidence and documenting manual accessibility observations.

This is a **recommended blueprint for collecting evidence from a manual accessibility check with Recorder**. Adapt the example to the keyboard, focus, label, or assistive-technology behavior you are checking. Recorder helps preserve the interaction and your observations; your testing process and companion tools determine the accessibility result.

The example below follows a dialog check: open it, navigate its controls with the keyboard, close it, and observe where focus returns. Use [test execution](https://fairleadhq.com/docs/recorder/test-execution/) when this is part of a larger case.

## Choose the mode and follow this 9-step path

Select **Test case** for a defined accessibility check with an authoritative case ID and a Passed/Failed/Blocked result. Select **Explore** for a newly observed keyboard, focus, label, or announcement problem; Explore has no Recorder result selector.

1. Choose the session type and enter the test case or optional issue reference.
2. In **Description**, record the build, browser/OS, assistive technology, settings, starting control, input method, and expected behavior.
3. Select **Start recording** and perform the check using the intended input method.
4. Observe focus or announcement before opening Recorder controls, then capture any visible state.
5. Select **Stop → Investigate** while the check remains in the [retained timeline](https://fairleadhq.com/docs/recorder/developers/capture-support/#recording-retention).
6. Compare the captured input, intended control, control/page response, and your manual observation.
7. Add source comments that say which part Recorder captured and which part you observed or obtained from a companion tool.
8. For Test case, choose Passed, Failed, or Blocked; for Explore, write the scoped finding and next check in Description.
9. Review, download or send, verify the attachment/result, and only then select **New recording**.

| Evidence | Recorder supplies | You must supply |
| --- | --- | --- |
| Input sequence | Supported actions and key events; Event Log detail | Starting focus, intended input method, and missing events |
| Control identity/state | Recorded role, labels, target context, and available state changes | Expected accessibility behavior and companion-tool interpretation |
| Focus/announcement | Partial visual or page-change context | Actual focus destination or spoken announcement and how it was observed |
| Result | Test case choices only | Scoped conclusion; Explore has no result control |
| Handoff | Description, Notes, images, report/download destinations | Tool versions, capture gaps, and external TMS or issue update |

## Prepare the context the recording cannot infer

Open the application and Recorder's side panel. Select the local or connected path. Prepare safe data and put the following in your test notes for the later description:

- Application build and the task being checked.
- Browser and OS, assistive technology and version, and relevant settings.
- Zoom or other display/input conditions you changed.
- Expected behavior, such as “Escape closes the dialog and focus returns to its opening button.”

Recorder's **Environment** tab provides available browser, viewport, and page context. Add assistive-technology settings and application build yourself. Use a title such as `TC-A11Y-8 - A1 - Dialog focus return`. A found issue can prefill an unchanged Title and offer its description; add that text only when it belongs in this attempt's unified Description.

## Capture the keyboard path

1. Select **Start recording** in the side panel and wait for the active state. Put focus at the agreed starting control in the application.
2. Perform the check using the intended input method. Keep track of the relevant keys and the observed focus destination; Recorder captures selected keys and shortcuts but not a complete focus history.
3. At a visible problem, use **Capture** for the viewport or **Area** for the affected region. Include enough of the page to identify the focused control or missing/incorrect label.
4. Select **Stop**, then **Investigate**. Keep the task inside the [retained timeline](https://fairleadhq.com/docs/recorder/developers/capture-support/#recording-retention).

Moving to Recorder's controls can itself change keyboard focus. Observe and write down the focus result before using those controls. If the screenshot no longer shows the original focus state, say so in its note rather than presenting the later state as proof. If a screen-reader announcement matters, record the wording you actually heard in your notes; Recorder does not capture its audio.

## Connect the input, control state, and observed effect

Investigate the chain **input → intended control → page/control response → observed focus or announcement**. Recorder can support parts of this chain; preserve your manual or companion-tool observation for the parts it does not capture.

1. Open **Actions → Recorded Actions** and turn **Key actions only** off; it hides keydown events. Use **Event Log** to inspect the captured key/action sequence and times. Identify the action before the failure rather than reconstructing a complete focus order from partial events.
2. Select the relevant action. In **Target**, inspect available **Role**, **Label**, **Aria label**, visible text, selector and frame context. Confirm that these identify the control you used, especially when several controls have the same label. Recorder's readable name can include inferred context; it is not a substitute for the actual accessibility tree or spoken announcement.
3. Inspect **What changed** and **Element & form state**, when present. For an expandable control, a captured expanded-state change helps distinguish “activation did not occur” from “activation occurred but the resulting focus/announcement was wrong.” Disabled or busy state can explain another blocked interaction. Absent state is not a recorded false value.
4. Open **Page changes** or **URL changed** if the action closes a dialog or navigates. If the control fetches content, open its related request and compare **Payload/Response** with the expected content. Check **Timeline** and **Timing** before treating a loading delay as a focus failure.
5. Right-click the useful target/state field → **Pin**, or pin the whole action for a sequence-level observation. Open the screenshot and pin it separately. In **Notes**, use **View evidence** to check that both concern the same point in the task, then add the manual focus/announcement observation with **Add comment → Save comment**.

For the dialog example, evidence that Escape was captured and the dialog closed supports the first part of the expectation. Whether focus returned to the opener still needs your observed focus destination or companion evidence. A screenshot taken after opening Recorder may identify the controls but no longer show that focus state.

If the intended action was captured but its state never changed, investigate activation/control state. If state changed and new content appeared but focus or announcement was wrong, preserve those successful transitions too: they narrow what the developer needs to reproduce. If input/state is missing, report the manual observation and gap instead of inventing the missing event.

## Attach a precise observation

For an input/focus finding, select the relevant action and choose **Add note**. For a visual finding, open **Screenshots & Attachments**, select the image, and choose **Add note** there.

Write enough context to separate captured evidence from what you observed manually:

```text
Input: pressed Escape after tabbing through the dialog controls.
Expected: dialog closes and focus returns to the opening button.
Observed manually: dialog closed; focus did not return to that button.
Screenshot: captured afterwards; opening Recorder changed focus, so this image only identifies the controls.
```

Adapt the last line to the actual image. If it clearly shows the original state, say what is visible. For an announcement, name the assistive technology and quote the observed wording, rather than suggesting the recording contains audio.

Select **Important** for the deciding finding, then **Save comment**. Open **Notes**, select the item, and use **View evidence** to confirm that it points to the intended action/image. Use **Edit comment → Save comment** for corrections; a comment draft is not saved just by closing its editor.

## Add companion-tool evidence and the result

If a companion tool provides an image, open the local Viewer and use **Screenshots & Attachments → Upload image**, **Paste image**, or drop the image on that tab. When clipboard access fails, use Upload image. State the tool, version, and origin in Description.

An image added after Stop is outside the frozen recording interval. Inspect its **Outside recorded period** label and use **Include in report** if it should accompany connected submission. This does not make the pictured event part of the captured interaction. Local downloads include available attachments regardless of that report-inclusion choice.

In **Description → Split**, write:

```markdown
Check / attempt: TC-A11Y-8 / A1 — dialog focus return
Build / browser / OS: [fill in]
Assistive technology / version / settings: [fill in]
Input sequence: [keys and starting control]
Expected: [focus, label, or announcement behavior]
Observed: [specific result and how you observed it]
Evidence: [NOTES]
Companion evidence: [tool output or attachment reference]
Capture limits: [missing events or altered screenshot state]
```

Select `[NOTES]` and choose **Add → Notes**. Review **Preview**, including any bare pins inserted with the comments. The copied text will not update if you later edit a source note. Resolve any description save error before export.

## Preserve and report

Open **Privacy preview** and inspect the authored text and image pixels as well as captured fields. Select **Download report**, confirm completion in Chrome, and open the summary, `notes.md` when present, and the images. Keep companion-tool outputs with the same case/attempt.

Attach the reviewed evidence to the test result or [bug report](https://fairleadhq.com/docs/recorder/bug-reporting/), then verify the attachments before **New recording** clears the local session. If the note points to the wrong source or says **Evidence unavailable**, preserve the written observation and explain the gap; add the correct evidence if still available.

Recorder provides no accessibility scanner, focus-path overlay, or conformance verdict. Keep the conclusion tied to the particular check and the tools used. The [shared workflow guide](https://fairleadhq.com/docs/recorder/testing-workflows/) covers download recovery and handoff choices.