Measure UI

Screenshots produce confident wrong conclusions, both false passes and false failures. Every claim about layout, fidelity, hover, focus, overflow or animation rests on a measurement: computed styles, rects and hit tests read in a live browser, asserted as numbers.

Pick the branch

• Fidelity: you have a design reference (a mockup, a design file, or your own earlier build) and an implementation, and need to prove they match or find why they differ.
• Interaction states: a dropdown, overlay, drawer or CSS animation looks broken, or you are about to claim an interactive change works.
• Visual parity: a styling-system migration or a reimplementation must not move a pixel; a frozen screenshot baseline and a zero image diff decide.

Matching a design usually needs both: fidelity for the static layout, then interaction states for every menu and animation.

Who does what

Proving a UI claim takes three skills, each owning one part:

• verify-this frames the claim and gives the verdict (VERIFIED, NOT VERIFIED or INCONCLUSIVE).
• This skill sets the evidence rules for anything visual or interactive: what to measure, how to actuate, what counts as proof.
• A driver only runs the browser: call the Skill tool with "control-ui" for a local browser or Electron app, or "orca" inside the Orca IDE.

Drivers locate elements by role, label or a stable data-* selector, then exercise them with real input at the element's measured position, then hit-test. A DOM element.click() through evaluate is fine for setting up state, never as the proof that a user can click it.

Rules for every measurement

• Actuate for real. Move the mouse with real pointer events (page.mouse.move(x, y)) to the trigger's measured centre. A driver's hover() followed by anything that moves the pointer leaves a stale position, and a working hover looks broken.
• Focus with real keys. Programmatic element.focus() sets document.activeElement, but :focus-within may not match without real document focus. Click a neutral element first, then send actual Tab presses.
• Click by pixel. Prefer trusted pixel clicks (page.mouse.click(x, y)) over clicking a visually hidden input by its accessibility ref. The ref click can flip the native control without driving the framework's state.
• Scope every query to the component (fieldset label, not label). An unscoped querySelectorAll('label') matched controls elsewhere on the page and reported a selection bug that did not exist.
• Hit-test. Visible is not clickable: document.elementFromPoint(x, y) must land inside the element you claim works.
• Catch horizontal overflow. document.documentElement.scrollWidth > window.innerWidth must be false at every width.

Confirm the CSS actually shipped

A class in the markup does not mean a rule exists. Build tools drop variants silently: Tailwind's group-focus-within/nav:visible once produced no rule, leaving a hover-only menu keyboard users could never open.

[...document.styleSheets]
  .flatMap(s => { try { return [...s.cssRules] } catch { return [] } })
  .filter(r => (r.cssText || '').includes('my-class'))
  .map(r => r.cssText.slice(0, 200));

Zero results on a state you rely on (especially :focus-within) means that path is dead. When an interaction must work, write the CSS explicitly (:hover, :focus-within) instead of composing it from variants.

Screenshot traps

Take screenshots only to confirm what the numbers already proved.

CSS pitfalls that repeatedly cause these bugs

Reporting

Quote the measured numbers: a value table (reference against implementation where there is one), computed values, rects, hit-test targets and per-width results. List what each verification actually exercised, and separate measured facts from inferences. "Looks right" is not evidence; a rect and a hit test are.