18 Playwright Visual and Accessibility Testing Interview Scenarios

Visual and accessibility interviews test whether you can choose an oracle, not whether you remember a matcher. A senior engineer must separate a genuine regression from rendering noise, identify which user experience is at risk, and preserve evidence that another reviewer can trust.

The scenarios below use checkout, navigation, account, and design-system examples. Answer each by naming the risk, the observable contract, the stability controls, and the review decision. A screenshot, an accessibility scan, and an ARIA snapshot answer different questions; treating them as interchangeable is the first design error to avoid.

Choose the Oracle from the Risk

The official Playwright visual comparisons guide explains that reference images are generated first and compared on later runs, with rendering consistency depending on the execution environment. Interview answers should begin one level higher: explain why pixels, semantics, or a targeted assertion is the right evidence for the defect under discussion.

Do not start by proposing a generous pixel threshold or a page-wide scan. First establish the state being exercised and the consequence of missing the defect. Then keep the oracle narrow enough that a failure points toward a decision.

Baseline Scope and Ownership

1. Why would you use a locator screenshot instead of a full-page screenshot?

For a pricing-card regression, I would capture the card when typography, spacing, and badge placement are the contract. A full page adds headers, recommendations, and personalized content that the test does not own. The locator image creates a smaller review surface and a more useful diff. I would still add functional assertions for the plan name and price because matching pixels alone does not prove business correctness.

2. How would you keep baselines reliable across developer laptops and CI?

I would generate and compare baselines in the same controlled browser, operating system, font set, viewport, color scheme, and device scale configuration. CI should be the authority if that is where merges are gated. Developers can inspect artifacts locally, but they should not casually regenerate platform-specific images from a different host. Container or runner changes require an explicit baseline migration with sampled review, not a mass acceptance.

3. Why is a baseline file a reviewed test asset rather than disposable output?

The baseline encodes the expected product state. I would version it beside the test, use a meaningful snapshot name, and require the pull request to show why it changed. Deleting and recreating images after every failure turns the assertion into approval theater. Reviewers should compare the requirement, expected image, actual image, and diff, then reject unexplained movement even when the new picture looks plausible.

Rendering Stability and Tolerances

4. How would you handle a dashboard with live timestamps and rotating announcements?

I would make the test data deterministic, fix the browser clock where time is part of setup, and mask only the announcement region if its content is outside this visual contract. If layout around the timestamp matters, replacing it with stable seeded text is better than masking the whole panel. A broad mask can hide clipping or overlap, so I would justify every excluded region and keep a separate assertion for its presence.

5. Why should fonts and animation settle before a screenshot assertion?

Late font substitution changes line breaks, while transitions can capture an intermediate layout. I would wait for an application-ready signal, use Playwright's screenshot animation handling, and ensure required fonts are installed in the baseline environment. Arbitrary sleep is weak because it guesses at readiness. The assertion should wait on observable page state, then compare the smallest meaningful surface.

import path from 'node:path'
import { test, expect } from '@playwright/test'

test('checkout summary keeps its approved layout', async ({ page }) => {
  await page.goto('/checkout?fixture=stable-order')
  await expect(page.getByTestId('checkout-ready')).toHaveText('ready')

  await expect(page.getByTestId('order-summary')).toHaveScreenshot(
    'order-summary.png',
    {
      animations: 'disabled',
      mask: [page.getByTestId('delivery-clock')],
      stylePath: path.join(__dirname, 'screenshot.css'),
    },
  )
})

6. How would you decide between masking, stylePath, and a diff threshold?

Mask a small dynamic region whose pixels are irrelevant, use stylePath when a test stylesheet can consistently neutralize volatility such as a third-party iframe, and apply a threshold only for understood renderer variation. I would not use all three reflexively. Each control removes signal. If a threshold tolerates the exact one-pixel border defect the test was created to catch, it has defeated the requirement.

Automated Accessibility Scenarios

7. Why is an axe scan not a complete accessibility verdict?

An automated engine can detect many rule-based issues, but it cannot judge every keyboard journey, screen-reader announcement, cognitive burden, or whether the interaction makes sense to users. I would run scans on representative states, add semantic and keyboard assertions for critical controls, and preserve manual assessment in the release strategy. In an interview, claiming zero violations means accessible is a serious overstatement of the evidence.

8. How would you scan a menu that is hidden until the user opens it?

I would navigate and interact with the menu exactly as a user does, assert that the expanded panel is visible, and only then run the scan against that region or page state. Scanning the initial DOM may miss content that is not rendered or active. I would also test focus movement, Escape behavior, and the trigger's expanded state because a rule scan cannot fully validate the interaction contract.

9. Why is excluding an entire component a risky way to handle known violations?

An exclusion prevents rules from evaluating that element and its descendants, so new defects can arrive unnoticed. I would prefer a narrowly documented exception tied to a tracked issue, with a fingerprint or targeted rule decision when practical. The team should retain full scan output as an artifact and periodically remove expired exceptions. Accessibility debt needs an owner and boundary, not a permanent blind spot.

ARIA Snapshot Design

10. How would you scope an ARIA snapshot for a complex checkout page?

I would snapshot the semantic subtree for the order form or confirmation dialog rather than the entire page. The template should express essential roles, accessible names, hierarchy, and stable states while omitting incidental content. Then I would keep direct assertions for the highest-risk controls. A concise snapshot tells a reviewer whether the accessible contract changed; a giant page tree encourages automatic updates without comprehension.

11. Why might an ARIA snapshot pass while the page is visually unusable?

The accessibility tree can preserve correct roles and names while CSS places a button off-screen, clips text, removes visible focus, or creates unreadable contrast. That is why semantic and visual evidence complement each other. For a primary action, I might combine a role-based locator, keyboard focus assertion, targeted screenshot, and manual contrast review. One oracle cannot establish every quality property of the rendered experience.

12. How should a team review an intentional ARIA snapshot change?

The pull request should connect the changed template to a product or accessibility requirement. I would inspect whether a role, name, level, state, or relationship changed and verify that assistive behavior improved as intended. Regeneration is not the review. If a heading level moved because a visual component changed, the reviewer must decide whether that semantic hierarchy is correct before accepting the snapshot.

Failure Triage and Evidence

13. How would you investigate a screenshot that fails only on one CI project?

I would compare project metadata, expected, actual, and diff images, then check fonts, viewport, browser channel, color scheme, locale, and test data. The spatial pattern matters: global text movement suggests fonts, isolated content suggests data, and a consistent edge may indicate layout. I would reproduce in the same environment before editing thresholds. Cross-project differences are evidence, not permission to normalize the failure away.

14. Why should baseline updates be separated from unrelated product changes?

Small, focused updates let reviewers understand causality. A large baseline sweep can conceal an accidental regression among legitimate changes and makes rollback difficult. I would regenerate only affected snapshots, inspect each diff, and include the reason in the review. If infrastructure intentionally changes rendering, I would stage a dedicated migration and sample critical screens across projects before replacing the old reference set.

15. How would you diagnose an accessibility scan that intermittently reports a missing label?

I would confirm the exact UI state and examine whether hydration, delayed localization, or conditional rendering changes the accessible name. The test should wait for the product's ready condition before scanning, not retry the scan until it happens to pass. I would attach the full result, DOM or trace evidence, and state inputs. If the label truly appears late, that can itself be an accessibility defect users encounter.

Coverage and Senior Tradeoffs

16. Why should critical workflows combine semantic assertions with visual checks?

Semantic assertions explain whether users and assistive technology can locate and understand controls; visual checks catch layout, clipping, and unintended styling changes. For payment confirmation, I would assert the heading, status, and actionable links, then visually compare the stable confirmation panel. The combination provides better diagnosis than either alone and keeps a cosmetic diff from being mistaken for proof that the transaction state is correct.

17. How would you choose which browser projects receive visual coverage?

I would use product usage, rendering risk, and component behavior, not assume every screenshot needs every project. A core design-system sample can run across relevant engines while broader page coverage uses the primary supported environment. Unique browser defects warrant targeted additions. The matrix should be affordable enough that diffs are reviewed promptly; duplicated images with no distinct risk increase storage and approval fatigue.

18. How would you defend the overall visual and accessibility strategy to a staff reviewer?

I would map critical journeys to their oracles, show how baselines and exceptions are owned, define the controlled rendering environment, and report which manual assessments remain. I would include failure triage time and stale-snapshot signals, not just test counts. The defense should make omissions visible: dynamic content, third-party UI, keyboard paths, screen-reader exercises, and browser-specific risk all need an explicit treatment or an accepted owner.

Interview Review Checklist

• State the user harm before naming a Playwright matcher.
• Explain why the selected surface is page-wide, component-level, semantic, or rule-based.
• Identify dynamic data, time, fonts, motion, browser, and host factors.
• Preserve expected, actual, diff, trace, and scan evidence where each is useful.
• Keep masks, exclusions, and thresholds narrow, documented, and removable.
• Require human review for baseline and semantic-template updates.
• Name what automation cannot establish and assign the remaining manual work.

Make the Final Answer Decisive

In the interview, finish with a decision: choose the oracle, define the stable state, show what failure evidence will exist, and state who approves a changed expectation. Reject vague proposals to update snapshots or ignore scanner noise. A senior answer protects signal while acknowledging residual risk. That is how visual and accessibility tests become reviewable product safeguards instead of a collection of fragile images and unexplained violations.