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 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.
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.

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:

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:

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, 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 covers download recovery and handoff choices.