Element Playground.

No id, name, or data-testid on this one — ARIA is the only strong option. This is intentional: plenty of real forms look exactly like this.

Disabled elements are still locatable — most frameworks require an explicit enabled-state check before you can interact with them.

No id, name, aria-label, or test id at all. In a real app, flag this to a developer — but you still need to test it today, so placeholder is the least-bad option.

This isn't a native <select> — it won't respond to selectOption(). Click the trigger, then click the option in the opened listbox.

aria-checked flips when toggled — don't hardcode the current state into your selector.

Becomes disabled and its text changes while loading — wait for the enabled state to return, don't just wait for the element to exist.

Despite being an <a> tag, role="button" makes accessibility-tree queries (Playwright's getByRole('button')) treat it as a button — don't assume tag name matches role.

target="_blank" opens a new tab/window — your test needs to handle the new page/window context, not just click and continue on the current page.

Doesn't exist in the DOM for the first 3 seconds after this section mounts — use an explicit wait/assertion with a timeout, not an immediate query.

Exists immediately but stays disabled for 5 seconds — wait for the disabled attribute to clear, don't just wait for the element to exist.

Text content changes every 2 seconds — don't assert exact text, assert a pattern or that the value changed between two reads.

The classic dynamic-ID trap — common in frameworks like Angular Material or MUI that auto-generate IDs. Always check whether an ID looks suspicious (long random suffix) before trusting it.

The options list doesn't exist until you type — query it after triggering input, not before.

New items only mount once you scroll near the bottom — for items beyond the initial batch, scroll the container into view first, then re-query.

Focus is trapped inside while open — Tab won't reach elements behind it. Close via Cancel/Confirm or Escape; there's no backdrop-click-to-close here.

Auto-dismisses after 3 seconds — assert on it immediately after triggering, don't add a long wait first or you'll query after it's gone.

The tooltip content is only in the DOM while the trigger is hovered or focused — hover() or focus() the trigger before asserting it's visible.

Triggered by the contextmenu event, not a normal click — most frameworks need an explicit right-click/contextmenu action, not click().

State-dependent — once dismissed it stays hidden (stored in localStorage) until you hit Reset. Good practice for testing first-visit vs. returning-visitor scenarios.

You must switch into the iframe's context before interacting with elements inside it (Playwright's frameLocator(), Selenium's driver.switchTo().frame()).

Two frame switches deep — switch into the outer frame, then into the inner one, before the button becomes reachable.

Real shadow DOM (mode: open). Playwright's locator() pierces shadow roots automatically; plain document.querySelectorAll/XPath cannot — try the Selector Tester below on a selector for the button inside and watch it return 0 matches.

Row order changes when sorted and the row set changes per page — don't hardcode 'row 3' as an identifier; locate by the cell's actual content instead.

Native HTML5 drag-and-drop doesn't respond to simple mouse-down/move/up sequences in most tools — use Playwright's dragTo() or Selenium's Actions dragAndDrop(), built specifically for this.

File inputs can't be 'typed' into for security reasons — use setInputFiles() (Playwright) or sendKeys(path) (Selenium) directly on the <input type="file">, never simulate a click-then-type.

All five buttons are byte-for-byte identical markup. If this were a real app, ask a developer for a unique attribute per row — until then, position is genuinely your only lever.

No id, class, or test id at all — just a bare <span>. In a real app, flag this to a developer; until then, text content is your only lever.

Every attribute on this button looks promising and is actually unreliable — a realistic example of why 'has an id' isn't the same as 'has a stable id'.

Classic 'find the button in the row that contains X' problem — most frameworks solve this with a scoped/filtered locator (e.g. Playwright's .filter({ has: ... })), not a single global CSS selector.