Visual &amp; Accessibility Testing Interview Questions for Playwright Testing

Show answer

Playwright cannot compare anything, so it captures the screenshot, saves it as the new baseline in the snapshots folder and marks the test as failed with a message that the snapshot was missing. On the next run the test compares against that file. This is why you review new baselines before committing them, and why baselines should be generated in the same environment that CI uses.

What is the difference between toHaveScreenshot and toMatchSnapshot?

Show answer

toHaveScreenshot is for images of a page or locator. It waits for the page to become visually stable, retries the capture until two shots match, and supports options like mask and animations. toMatchSnapshot compares any value you pass in, such as a string, a buffer or text output, against a stored file, without waiting or retrying. Use toHaveScreenshot for UI and toMatchSnapshot for generated text or file content.

Why should CSS animations be disabled for visual comparisons?

Show answer

An animation captured at a slightly different frame produces a different image, so the test fails even though nothing is broken. With animations: 'disabled', which is the default for toHaveScreenshot, Playwright fast-forwards finite animations to their end state and resets infinite ones to their start. This gives the same picture every run. Transitions triggered by hover or focus are handled the same way.

Where does Playwright store baseline screenshots and how are the files named?

Show answer

By default baselines go into a folder next to the test file named after it, for example checkout.spec.ts-snapshots. The file name combines the name you give, the project name and the platform, such as home-chromium-linux.png. Because the browser and operating system are part of the name, each project keeps its own baseline. You commit these images to the repository so every run compares against the same files.

How do you update screenshot baselines after an intended UI change?

Show answer

Run the tests with npx playwright test --update-snapshots, optionally filtered to the affected files or a tag. Playwright rewrites the baselines with the new images. Newer versions also accept modes such as --update-snapshots=changed or missing so only the needed files are touched. Always look at the diff in the pull request before merging, because blindly updating hides real regressions.

Write a test that compares only the pricing card instead of the full page.

Show answer

test('pricing card looks right', async ({ page }) => { await page.goto('/pricing'); const card = page.getByRole('region', { name: 'Pro plan' }); // screenshot is clipped to the element await expect(card).toHaveScreenshot('pro-plan.png'); });

How do you check colour contrast in Playwright tests?

Show answer

Playwright has no built-in contrast assertion, so you run axe-core through @axe-core/playwright, whose color-contrast rule checks text against WCAG ratios such as 4.5 to 1 for normal text. Scan pages in each theme, for example after emulating dark mode with colorScheme. Axe may report some elements as needing review, for example text over images, and those need a manual look.

A screenshot test fails with only a few pixels different because of anti-aliasing. What do you do?

Show answer

Open the diff image in the HTML report to confirm it is just edge smoothing and not a real change. If baselines were made on a different machine, regenerate them in the CI image. If the noise is genuine and repeatable, allow a small maxDiffPixels for that assertion or project. Avoid large ratios, because they also let real layout shifts through.

A screenshot of a search page is flaky because a blinking text cursor appears in the input. How do you fix it?

Show answer

toHaveScreenshot hides the text caret by default with caret: 'hide', so check that nobody set it to 'initial' and that you are not using page.screenshot with toMatchSnapshot, which lacks some of these defaults. Also blur the input or click elsewhere before the capture if focus styles change. Using the dedicated assertion gives you stable captures and retries.

What do maxDiffPixels, maxDiffPixelRatio and threshold control in a screenshot comparison?

Show answer

threshold sets how different two pixels can be in colour, from 0 to 1, before they count as different; the default is 0.2. maxDiffPixels allows a fixed number of differing pixels, and maxDiffPixelRatio allows a fraction of the total image. Keep them tight so real regressions fail, and set them in the expect section of the config rather than loosening single tests one by one.

Write a visual assertion that masks a live clock and an ad banner.

Show answer

// masked areas are painted with a solid box await expect(page).toHaveScreenshot('home.png', { mask: [ page.getByTestId('live-clock'), page.locator('.ad-banner'), ], maskColor: '#FF00FF', animations: 'disabled', fullPage: true, });

Visual tests pass on developers' laptops but fail in CI with tiny font differences. Why, and how do you fix it?

Show answer

Font rendering, anti-aliasing and installed fonts differ between Windows, macOS and Linux, so the same page produces slightly different pixels. The fix is to generate and compare baselines in one fixed environment, usually the official Playwright Docker image used in CI. Developers update baselines by running that container locally or through a CI job, not from their own machines. Loosening thresholds should be the last resort.

How can you apply extra CSS only while a screenshot is taken?

Show answer

Pass the stylePath option to toHaveScreenshot or set it in the expect.toHaveScreenshot section of the config. The stylesheet is injected just for the capture, so you can hide scrollbars, freeze a carousel, or set visibility hidden on dynamic widgets without changing the app. It is cleaner than adding test-only classes and also works when a mask box would cover too much of the layout.

Write an accessibility scan that checks only WCAG 2.1 A and AA rules.

Show answer

import { test, expect } from '@playwright/test'; import AxeBuilder from '@axe-core/playwright'; test('signup page has no WCAG A/AA issues', async ({ page }) => { await page.goto('/signup'); const results = await new AxeBuilder({ page }) .withTags(['wcag2a', 'wcag2aa', 'wcag21a', 'wcag21aa']) .analyze(); expect(results.violations).toEqual([]); });

How do you exclude a third-party widget or switch off one rule in an axe scan?

Show answer

// scan the page but skip the chat widget you do not own const results = await new AxeBuilder({ page }) .include('main') .exclude('#third-party-chat') .disableRules(['duplicate-id']) .analyze(); expect(results.violations).toEqual([]); // log a ticket for anything you exclude

What do toHaveAccessibleName and toHaveAccessibleDescription check?

Show answer

They assert the name and description that assistive technology computes for an element, using the accessibility tree rather than raw attributes. The name may come from a label, aria-label, aria-labelledby or inner text, and the description often from aria-describedby. For example an icon-only close button should have the name Close. These checks catch problems that a plain text assertion would miss.

What is an ARIA snapshot and how does toMatchAriaSnapshot work?

Show answer

An ARIA snapshot is a YAML description of the accessibility tree for a part of the page: roles, names and states such as checked or level. toMatchAriaSnapshot compares the live tree of a locator against that template, and partial templates or regular expressions can be used for changing text. It tests structure and semantics, so it survives styling changes that would break a pixel screenshot.

Write a test that checks keyboard Tab order through a login form.

Show answer

test('login form is keyboard friendly', async ({ page }) => { await page.goto('/login'); await page.getByLabel('Email').focus(); await page.keyboard.press('Tab'); await expect(page.getByLabel('Password')).toBeFocused(); await page.keyboard.press('Tab'); await expect(page.getByRole('button', { name: 'Sign in' })).toBeFocused(); await page.keyboard.press('Enter'); });

What can automated accessibility tools not catch?

Show answer

Scanners like axe find rule-based problems such as missing labels, bad contrast or invalid ARIA, which is roughly a third to a half of real issues. They cannot judge whether alt text is meaningful, whether focus order makes sense, whether error messages are understandable, or whether a screen reader user can actually finish the task. So automated scans are combined with keyboard tests and periodic manual checks with screen readers.

How do you attach axe results to the Playwright HTML report?

Show answer

test('cart is accessible', async ({ page }, testInfo) => { await page.goto('/cart'); const results = await new AxeBuilder({ page }).analyze(); await testInfo.attach('axe-results', { body: JSON.stringify(results.violations, null, 2), contentType: 'application/json', }); expect(results.violations).toEqual([]); });

How do you run the same visual tests at mobile, tablet and desktop sizes?

Show answer

Create one project per size in playwright.config, for example using devices['Pixel 7'], devices['iPad Mini'] and a desktop viewport, and point them at the same visual test files with testMatch or a tag. Because the project name is part of the baseline file name, each size keeps its own images automatically. This keeps the test code identical while covering responsive layouts.

Why are screenshot baselines specific to browser and operating system?

Show answer

Each browser engine lays out and paints text, shadows and form controls slightly differently, and each operating system has its own fonts and smoothing. A Chromium image on Linux will rarely match WebKit on macOS pixel for pixel. That is why Playwright includes project and platform in the file name and why teams fix one rendering environment for baselines.

Tell me about a time an accessibility check caught a real issue before release.

Show answer

Situation: a new checkout redesign was ready for release. Task: I had just added an axe scan to our Playwright smoke tests. Action: the scan flagged that the payment form inputs had placeholder text but no labels, and a keyboard test showed the pay button was unreachable with Tab. I raised it with screenshots and the rule links. Result: the developer fixed both in a day and the release went out on time.

Baselines are always rendered in Docker, yet the repo has separate Windows and Linux image files. How do you keep one baseline per browser?

Show answer

The default file name includes the platform, so a developer who updated baselines on Windows created a second set. Set snapshotPathTemplate in the config without the {platform} token, for example '{testDir}/__screenshots__/{testFilePath}/{arg}-{projectName}{ext}', delete the stray files and only update baselines through the Docker command or a CI job. Document the rule so it does not happen again.

A designer changes the primary button colour and 300 visual tests fail at once. How do you handle it?

Show answer

First confirm the change is intended and check a sample of diffs to make sure nothing else moved. Then regenerate baselines in the CI Docker environment in a separate commit, so reviewers can see only image changes. Longer term, reduce the count: most of those tests should not snapshot full pages. Keep a few page-level shots and move detail checks to component-level screenshots of key states.

How would you design a visual testing strategy for a large web application?

Show answer

Snapshot stable, high-value screens and shared components, not every page. Render baselines only in a pinned Docker image, mask or mock dynamic data, and disable animations. Keep visual tests in their own project or tag so they can run on pull requests touching UI code. Define owners for baseline reviews and keep thresholds strict in config. Combine with functional assertions, because pictures alone do not tell you why something broke.

An axe scan reports 40 violations on a legacy page. How do you add accessibility checks without blocking every build?

Show answer

Record the current violations as a known baseline, for example by snapshotting violation ids and targets, and fail only on new ones. Fix the worst issues first, such as missing labels and contrast on key flows, and shrink the baseline every sprint. Make new pages and components meet zero violations from day one. Report the trend to the team so the debt is visible rather than silently ignored.

How do you test that a modal dialog traps focus and returns it when closed?

Show answer

Open the dialog with a button and assert the dialog role is visible and focus moved inside it. Press Tab more times than there are controls and check with toBeFocused that focus never leaves the dialog. Press Escape, assert the dialog is hidden, and check that the opening button is focused again. Running the same test with Shift+Tab covers backward navigation as well.

Images load lazily and are sometimes missing from full-page screenshots. How do you make them stable?

Show answer

Scroll the content into view or remove loading=lazy for the test, then wait until every image has loaded, for example with expect.poll checking that all img elements report complete and a natural width above zero. Serving images from mocked routes removes network timing too. Only after that call toHaveScreenshot, which then waits for two identical frames.

When is visual regression testing a poor fit?

Show answer

It works badly for highly dynamic pages such as live feeds, personalised dashboards or content managed by editors, where most diffs are expected. It is also costly when the design changes every sprint, because baseline reviews eat time. In those cases use functional assertions, ARIA snapshots or component-level screenshots of fixed states instead of full-page pictures.

Describe how you convinced a team to adopt accessibility testing.