Smart Locators Node

The Smart Locators node allows you to automate interactions with web pages using Playwright's semantic locators — based on ARIA roles, labels, placeholders, and other accessibility attributes. This approach is more resilient than CSS selectors, as it reflects how users actually find elements on the page.

Tip: If you prefer traditional CSS selectors and XPath, use the Web Flow node.

Overview

General Configuration

Identical to the Web Flow node:

The Browser & Device options are identical to the Web Flow node — see the Web Flow documentation for details on viewport presets and available mobile devices.

Locator System

Location Methods

Instead of CSS selectors, Smart Locators uses Playwright's semantic methods:

Locator Configuration

Available ARIA Roles

For the getByRole method, the following roles are available:

Usage example:

Method: getByRole
Value: button
Name: Sign In

Equivalent in Playwright: page.getByRole('button', { name: 'Sign In' })

Available Actions

Action Details

navigate

Navigates to a URL.

click

Clicks on a semantically located element.

The click waits for the element to be visible, scrolls to it if necessary, and then clicks. If it fails, it retries.

Example:

Method: getByRole
Value: button
Name: Submit
Retries: 3

dblclick

Double-clicks on an element.

fill

Fills an input field instantly (replaces the value).

Uses Playwright's locator.fill() — ideal for simple fields.

type

Types text character by character, simulating real typing.

Uses Playwright's locator.pressSequentially() — ideal for fields with:

• Autocomplete (suggestions appear as you type)
• Input masks (phone numbers, zip codes)
• On-keypress validation (validates each key)

Example:

Locator: getByPlaceholder → "Phone"
Text: 123.456.789-00
Delay: 100ms

check / uncheck

Checks or unchecks a checkbox/radio button.

Example:

Method: getByLabel
Value: I accept the terms of use

selectOption

Selects an option from a dropdown (<select>).

hover

Hovers the mouse over an element.

focus

Sets focus on an element.

press

Presses a keyboard key in the context of an element.

assert

Verifies conditions on the page. Offers multiple verification modes:

Assert Modes:

Examples:

// Verify that the "Submit" button is visible
Mode: visible, Locator: getByRole("button", "Submit")

// Verify that message contains "Success"
Mode: textContains, Locator: getByText("Success"), Expected: "Success"

// Verify URL after login
Mode: hasURL, Expected: "/dashboard"

// Verify that field is disabled
Mode: disabled, Locator: getByLabel("Email")

extract

Extracts data from an element.

Available attributes:

wait

Waits for a condition.

scroll

Scrolls the page.

refresh

Reloads the page. Same configuration as Web Flow.

frame

Switches to an iframe. Supports name and main modes (return to main context).

Evidence (Screenshots per Step)

Identical to Web Flow — each step can have individual screenshot capture configuration.

Accessibility Testing

Smart Locators supports automatic accessibility scanning with built-in axe-core. When enabled, the node audits the page after each step that captures a screenshot, identifying WCAG/ARIA violations and visually marking the affected elements.

Smart Locators already uses semantic locators based on ARIA roles — combining it with accessibility scanning is especially useful for verifying that the elements you interact with pass accessibility criteria.

Configuration

How It Works

After each step that takes a screenshot, axe-core is injected into the page and scans the document for violations. Violations are drawn over the screenshot as colored boxes around the affected elements, plus a summary panel in the corner:

At the end of execution, the following are generated automatically:

• Per-step screenshots — overlay with colored boxes + panel Critical N / Serious N / Moderate N / Minor N + top 2 rules
• Severity chart — {id}-accessibility-severity-chart.png — distribution by level
• Rules chart — {id}-accessibility-rule-chart.png — top 8 most violated rules
• JSON report — {id}-accessibility-report.json — full data for all violations

Pass/Fail Criteria

The node fails if there is any violation with severity equal to or above the configured threshold. Use none to never fail (collect metrics without blocking the flow).

Example: Verify login form accessibility

Node configuration:
  Accessibility Scan: true
  Fail When Severity >= : serious

Steps:
1. navigate → https://mysite.com/login            (no screenshot = no scan)
2. fill → getByLabel("Email") → "..."              → screenshot after → scan executed
3. fill → getByLabel("Password") → "..."           → screenshot after → scan executed
4. click → getByRole("button", { name: "Sign In" }) → screenshot after → scan executed
5. wait → networkIdle
6. assert → "loginOk" → textContains → getByText("Welcome") → screenshot → scan executed

If any step has a serious or critical violation, the node fails with:

"Accessibility findings at or above "serious" were detected."

Outputs

Complete Example: Login with Smart Locators

Step 1: navigate → https://mysite.com/login
Step 2: fill → getByLabel("Email") → "{{ variables.EMAIL }}"
Step 3: fill → getByLabel("Password") → "{{ variables.PASSWORD }}"
Step 4: click → getByRole("button", { name: "Sign In" })
Step 5: wait → networkIdle
Step 6: assert → "loginOk" → textContains → getByText("Welcome")
Step 7: extract → "userName" → getByRole("heading") → text

When to Use Smart Locators vs Web Flow

Tips

• Prefer getByRole — it is the most resilient and reflects how assistive technologies find elements
• Use getByLabel for form fields — it is more stable than CSS
• getByTestId is great for elements without a clear role/label
• Use the type action (instead of fill) for fields with masks or autocomplete
• The Nth field allows you to select a specific element when multiple ones match the locator