Across a large Playwright suite, how do you decide which pages get an aria snapshot without creating constant template churn?

## What an aria snapshot is worth One `toMatchAriaSnapshot` line covers a whole surface. For the price of a locator and a template it defends every role, accessible name and heading level under that element, which is coverage no reasonable number of hand-written assertions would reach. It is a **net**, not a probe: it does not know what matters, it notices that something moved. That property sets both the value and the cost. The value is catching the change nobody wrote a test for, a renamed export control, a heading demoted during a redesign, a widget that stopped rendering for logged-out users. The cost is that every intended edit inside the covered surface produces a template diff that a human must read and approve. ## Choosing surfaces Rank candidate surfaces by how much the structure is a contract and how stable it is: 1. **High-value, stable surfaces first.** The statement page's main region, the balance widget, the export control: things whose disappearance is a serious defect and whose structure changes rarely. 2. **Composed surfaces over leaf components.** A snapshot earns most where several pieces come together and nobody owns the whole, which is exactly where a missing widget slips through. 3. **Not on surfaces in active redesign.** A template on a page being reworked weekly generates pure noise and teaches the team to regenerate without reading. 4. **Not as a substitute for behaviour tests.** Structure being present is not the same as export producing a file; keep targeted assertions for what the feature does. ## Keeping templates small | Approach | Catches | Churn | | --- | --- | --- | | Whole `body` on every page | Almost any structural change site-wide | Very high, every banner edit hits every test | | `main` on a few key pages | Page-level structure and outline | Moderate, page redesigns only | | One named region per critical widget | That widget's roles, names and states | Low, changes are usually intended | | No snapshot, targeted matchers only | Exactly what was written down | None, and misses silent removals | The middle two rows are where a suite should mostly live. A template that covers more than the test cares about is the root cause of nearly all snapshot fatigue. ## An update policy people can actually hold - Regeneration is scoped to the spec being changed, never the suite, so unrelated failures stay failures. - A regenerated template ships in the same commit as the change that caused it. - Reviewers treat a lone removed line, a lost heading or region, as a question rather than noise. - File-backed templates on shared pages, so the diff is visible in review rather than buried in a test body. ## Signals a template has outgrown its test - It is rewritten in most pull requests that touch the area at all. - Nobody can say in one sentence what it defends. - Its regenerations are approved in seconds, which means the check has become ceremony. - Two tests keep failing together on the same edit, meaning their templates overlap. The response to any of these is to **shrink the surface**, not to delete the assertion and not to regenerate harder. A smaller template on the region that genuinely matters keeps the property worth having, that somebody finds out when a control quietly loses its name, while paying for a diff only when the structure of that region was really meant to change.