New · Application pages
Your components are proven. Now prove the pages they build.
Tell Coverli which routes matter. Every deployment your host reports is captured at desktop, tablet and phone widths, checked against the rules, walked for its title, landmarks, headings and focus order, and compared with what you approved. One decision per page.
application pages · /checkout
deploy preview · a91f0c2At phone width the order total dropped below the Place order button. Flagged on this deploy, held until someone decides. Desktop and tablet are byte-identical to the approved captures.
01 · Connect
Your deploys are the trigger.
When your host reports that a preview is ready, Coverli tests that URL. There is nothing to add to your pipeline and no test runner to install.
One confirmation, once: an admin confirms the host the first deployment names. Coverli never visits a host nobody approved.
- GitHub Pages
- Every successful deployment GitHub records on the host you confirmed.
- Netlify deploy previews
- Every pull request's preview, the moment it is ready.
- Anything on GitHub Deployments
- Any host that reports a deployment and its URL to GitHub.
deploy → run
nothing added to your CI- 14:01:08deploy preview ready · a91f0c2
- 14:01:09confirmed host · 3 registered pages
- 14:01:10run queued · 1280 / 768 / 375 · rules, capture, navigation transcript
- 14:02:319 captures · 1 changed · review opened · status posted to the pull request
Your host reports the deployment. Coverli tests that URL. The result lands on the pull request, beside the component run for the same commit when the repository has one.
page registry · storefront
3 of 11 proposed routes| path | label | masks | wait for |
|---|---|---|---|
| / | Home | — | — |
| /checkout | Checkout | [data-live=totals] | form[name=payment] |
| /account/settings | Settings | .avatar, time | — |
Discovery proposes the routes it finds on your deploy; you tick the ones that matter. A mask hides a region that is meant to change. A wait-for selector says when the page is ready. That is the whole configuration.
02 · Register
Pages, not scripts.
Coverli looks at your deploy and proposes the routes it finds. You tick the ones that matter and give each a label. That is the configuration. No test code, no journeys to script.
Two optional settings per page: masks for regions that are meant to change, such as a clock or a feed, and a wait-for selector that tells us when the page is ready.
03 · Capture
Three widths. One decision.
Each page is captured full-page at desktop, tablet and phone widths and compared with the approved capture for that page and width. A reviewer decides once per page, and the decision covers all three.
Capture is pinned: frozen clock, fixed widths, held animations. A region that is meant to change is masked rather than tuned with a threshold, and a page that disagrees with itself is flagged unstable, never as a change. What did change is reported for what it is: the order summary moved, the page grew taller.
- Frozen clock
- Time does not advance during capture, at any width.
- Parked animations
- Motion is held still before the shutter opens.
- Pinned width and density
- Desktop, tablet and phone are fixed sizes, captured full-page.
- Declared masks
- A region that is meant to change is masked by name, never tuned as a threshold.
- Ready when you say
- A wait-for selector, then a quiet network, then a sweep that wakes lazy content.
- Read-only
- Nothing is clicked, typed or submitted. Dialogs are dismissed and counted.
04 · Hear the structure
What a screen reader user meets first.
Before anyone reads a word of content they meet the page title, the landmarks, the heading outline, and the order keyboard focus travels. Coverli records all four on every deployment, in the screen reader's own words, and flags the deployment that changes them.
The boundary, stated: real NVDA and VoiceOver transcripts are captured per component, where every state can be reached. On pages, the navigation transcript is taken with the same virtual reader that covers every commit of your components.
navigation transcript · /checkout
virtual reader · 1280- title
- Checkout — Acme Store
- landmarks
- banner · navigation, Main · main · contentinfo
- headings
- heading, Checkout, level 1 · heading, Your order, level 2 · heading, Payment, level 2
- focus orderchanged
approved · link, Skip to content → link, Home → link, Cart, 2 items → textbox, Card number …
this deploy · link, Home → link, Cart, 2 items → textbox, Card number …
The skip link is gone. A keyboard user now tabs through the whole header to reach the form. Held for a decision, with the markup that caused it.
Nothing new to learn
Pages share everything with your components.
The same review
Pages are reviewed on the same run and review pages as your components, with the same compare views, the same comments, and one decision per page across all three widths.
The same pull request
A pages run posts its own status and its own comment beside the component run for the same commit, each linking the other's report.
The same memory
Approvals are recorded with a name and a time. A new approval supersedes the old one; nothing is overwritten.
The same meter
One page at one width is one snapshot, on the same meter as a component capture. Pages are not a separate product.
A Storybook project and a pages project can live on the same repository and name each other as companions, so the component run and the page run for one commit sit side by side.
Not on pages yet
Where it stops today.
Real NVDA and VoiceOver walks of a page, the expert audit of an assembled page, and pages behind a login are not built yet, and page runs are managed-mode only for now. We would rather say which than let you find out during a pilot. Components have the first two today.
“A page scanner hands you a number per URL. We photograph the page at three widths, compare it with what a named person approved, record what a screen reader meets first, and hold the merge until someone decides.”