Keep the screenshot. Add the context.

Element context is information about a UI element at a particular moment: its identity, surrounding structure, and relevant state. That could include a button’s role, accessible name, attributes, and a locator scoped to the right section.

Keep the screenshot. It can reveal clipped text, misplaced controls, and visual overlap that an element’s markup does not establish. For a canvas or other interface with little useful DOM structure, visual evidence may be essential.

Some agents already act through images and coordinates, as in Anthropic’s computer-use tools. Add DOM and accessibility details when they help resolve the question the image leaves open.

The same principle appears in Playwright’s Trace Viewer, which puts captured screenshots and DOM snapshots beside the actions from a test run.

These two versions of “Export CSV” look identical. One is enabled; the other has a native disabled attribute. Switch states, try the button, and compare the element details below.

<section aria-label="Usage report">
  <button type="button" data-testid="export-csv">
    Export CSV
  </button>
</section>

A local teaching example with fictional data. The buttons are deliberately styled alike to isolate the difference; a real interface should make its disabled state clear.

This example uses HTML’s native disabled attribute. By contrast, aria-disabled communicates a disabled state but does not itself prevent activation. Custom controls need behavior that matches their semantics.

Element details narrow the question. They do not remove the need to check the current page. A target can move, be replaced, or become unavailable after a navigation or UI update.

1. 01

   Identify the intended control.

   Use the section, role, and name to distinguish it from similar controls. Confirm the locator matches one intended element.

2. 02

   Check whether it can be used now.

   Inspect the current state. A visible, enabled button may still be moving or covered by another element.

3. 03

   Check what the action actually did.

   For an export, confirm the download and its contents. A click event or success message is only part of the evidence.

import { expect } from '@playwright/test';

// Run on your report page after the relevant setup.
const report = page.getByRole('region', {
  name: 'Usage report', exact: true,
});
const exportButton = report.getByRole('button', {
  name: 'Export CSV', exact: true,
});

await expect(exportButton).toHaveCount(1);
await expect(exportButton).toBeVisible();
await expect(exportButton).toBeEnabled();

// Click also checks stability and whether the target receives events.
await exportButton.click();

// Add an assertion for your app's actual export result.
// A successful click does not verify a file's contents.

Playwright locators resolve against the current DOM. Its actionability checks cover conditions such as visibility, stability, receiving events, and being enabled before a click.

Finding disabled explains why the native button cannot be activated. It does not explain why the application disabled it. That could require the preceding steps, validation state, account permissions, or a relevant request and response.

Include the relevant moment from the recording, what you expected, and what happened. Keep the capture time and environment with the evidence. If a field or earlier step was not captured, say so instead of filling the gap with a guess.