After repairing the Sellavie workspace theme, I wanted to know whether contrast was right across the whole workspace, not on the three screens I happened to open.
Why checking components was not enough
A button can pass on its own and fail on the page. Contrast is a property of a pair: the text and whatever ends up behind it. That depends on the theme, the panel the element sits in, its state and the width of the screen.
Measuring what is actually rendered
I wrote a crawler with Playwright that signs in, visits 22 workspace routes and records the contrast of the text and background pairs that are really on screen.
The first run found failures I would not have found by eye. One dark panel had text at 1.04:1, which is close to invisible. Inactive labels in the mobile navigation were at 2.5:1.
Fixing sources, not symptoms
Each failure traced back to a token or a shared surface, so that is where I fixed it. The panel went to 17.8:1 and the navigation labels to 7.6:1. Because the change was made at the source, every route using those tokens improved with it. The final sweep reported no AA contrast failures across the workspace.
Why I kept the crawler
It runs against the real signed-in layouts, so a token change that breaks contrast on a route I am not looking at shows up as a failure. Accessibility stops being something checked once and becomes something every change has to keep passing.
What it does not tell me
A crawler measures contrast. It does not tell me whether a screen makes sense with a keyboard or a screen reader. That still needs a person.