We captured 40 pages of designsystem.digital.gov with Stage1 and compared what they render with the Figma kit the USWDS team publishes. The comparison found no unexplained value drift in this sample. Some values match the kit exactly. Others are explained by the site’s CSS or excluded from the comparison, and font weight has no declared values to compare.
The remaining gap is in the names. USWDS uses kit colors for inputs and outline buttons, but the kit doesn’t assign most of those colors a border role. Someone building from the kit still has to read the site’s code to find that choice.
This revision
We measured the site again on October 7 with Stage1 0.5.0. The twelve findings in our October 4 revision came from two patterns: outline borders drawn as inset shadows, and icon-list padding set relative to the typeface’s x-height. The new comparison reads both differently:
- An inset shadow with spread but no offset or blur is a stroke. Stage1 now compares its color under the border rules while keeping it in the shadow family. Of the ten stroke values, one has an exact border-role match, eight use kit colors without a border role, and one is translucent and excluded.
- The icon-list titles declare
0.425extop padding. Stage1 now reads that authored declaration as the explanation for the 3.23px and 4.02px values, rather than treating them as missing spacing tokens.
The comparison also reads all four border sides. The previous run read only the top, so the border counts changed. These are changes in what the measurement can explain, not evidence that USWDS fixed twelve defects. Explained values do not become exact token matches.
We first published this report on September 30. The October 4 revision corrected three of our explanations, which still matter:
- The 37.44px heading margins are twice an 18.72px heading, and 18.72px is Chrome’s default size for an h3, not a USWDS type step.
- The -12px and -16px margins belong to the mobile menu’s close button, which isn’t painted at the desktop width we captured. They aren’t kit steps made negative.
- The kit does have type sizes for Merriweather.
On Stage1 0.6.0. Stage1 0.6.0 reads the kit in two new ways. It records the scopes a Figma variable is published for, and it resolves each variable’s value mode by mode. On this capture it counts 3 of 12 border colors and 7 of 9 inset strokes as border-role matches. Each new match comes from one of those readings: a step-indicator color the kit scopes for strokes as well as fills and text, or a value the kit uses only in its default or dark mode. White, for example, is the table border only in dark mode. A scope or a mode says a color may be used for a stroke. It doesn’t say the kit meant it for these elements, so this report keeps the stricter reading and stays on 0.5.0.
What we compared
The site is designsystem.digital.gov, captured on October 7, 2026. Stage1 followed links two deep from the home page and captured 40 pages: the home page, 11 About pages, the component index and 27 component pages. The sitemap lists 257 URLs. The value comparison covers 7,745 sampled elements in Chrome’s light mode at a width of 1280px.
The site is built on USWDS 3.14.0. The kit is uswds-design-kit-beta.fig from the uswds-for-designers repository, pinned to the same file as the earlier reports. Its README calls it beta 0.3, tracking USWDS 3.11.0. Stage1 read 1,831 tokens from it and resolved every one. 627 of them are deleted tokens that Figma no longer shows but the file still holds.
Both are in the public domain. We aren’t affiliated with GSA or the USWDS team, and nothing here is an endorsement.
How a match works
Stage1 compares exact values, such as a color’s hex code or a radius in pixels. A value the kit defines is a match, from any of its themes or font options, so a match doesn’t say which theme it came from. The site’s primary blue, #005ea2, is the primary of the kit’s Default theme.
The comparison lists browser defaults, unpainted elements and third-party content separately. It also records explanations from the authored CSS, such as a length relative to a font or a kit step made negative. A border color can be in the kit’s palette without having a border role. None of those explanations counts as an exact match or as drift.
Type is compared per typeface, against the sizes the kit declares for each one. USWDS scales type for each typeface, so a size within a fixed 0.16px rounding step of the kit’s is explained rather than flagged.
What the comparison found
- Color: all 38 compared solid colors are in the kit. Six translucent colors sit outside the comparison.
- Radius: all four compared radii are in the kit.
- Type: 7 of the 22 compared type sizes match exactly. The other 15 are within the rounding step.
- Spacing: 14 of the 21 compared padding and margin values match kit tokens. Six are explained by authored font-relative lengths, and one is a kit step made negative.
- Borders: one of the 12 compared colors, the card border #e6e6e6, has a border role in the kit. The other 11 are kit colors without one. Three translucent colors are excluded.
- Shadows: one of the nine compared inset strokes has an exact border-role match. The other eight use kit colors without a border role. A tenth stroke is translucent and excluded.
There are no unexplained value-drift signals. The exact-match ratios remain 7/22 for type, 14/21 for spacing, 1/12 for borders and 1/9 for shadows. Explanations do not raise them.
What the CSS explains
The icon list’s titles use 0.425ex top padding, a fraction of the typeface’s x-height. It renders at 3.23px on three sampled titles and 4.02px on three others. The declaration explains those values; neither is a spacing token in the kit.
USWDS draws outline buttons with a 2px inset shadow. The header’s gold outline and the blue feedback launcher use kit colors, but those colors have no border role there. The translucent white outline is excluded under the comparison’s alpha policy. Only the #e6e6e6 stroke matches a color named for a border.
Other explanations remain separate: Chrome supplies some documentation heading sizes and button padding, and the hidden feedback form and mobile menu contribute values on elements that weren’t painted when we captured them.
The values agree. The names don’t.
The kit names six colors for borders or strokes: on cards, the summary box, tables and process-list counters, accordions, and one focus state, whose color has been deleted from the kit but is still in the file. None of them is for inputs. Text inputs use gray #5c5c5c. It’s in the kit’s palette. It has no border role there.
A token named for its role is what lets a designer, or an agent generating screens, pick the right gray without reading the CSS. The code has made this choice. The kit doesn’t record it.
What we didn’t score
Font weight. There are four live values, but the kit has no weight tokens to compare them with. Its weights live inside text styles. This family is unjudged and has no conformance ratio.
Theme. A value can match any declared theme mode. That doesn’t establish which theme the site ships.
Excluded values. Translucent colors and one unrecognized spacing value are outside the comparison. They haven’t passed a check.
The rest of the site and its states. We didn’t capture 217 of the 257 sitemap URLs. This value comparison reads sampled elements in the main document, in light mode at the captured width. It doesn’t establish agreement for other pages, dark mode, embedded documents or every interactive state. The network trace for /about/monthly-calls is partial.
Three releases apart
The kit tracks USWDS 3.11.0 and the site runs 3.14.0. The outline strokes and x-height padding were already in 3.11.0’s code. This sample shows no unexplained value gap under the recorded rules. It doesn’t establish that components added since 3.11 exist in the kit, or that components with matching values behave the same way.
Run it yourself
This report uses Stage1 0.5.0. It needs Node 22 (22.19 or later within 22.x) or Node 24.
npm install --global @aquex/[email protected]
stage1 inspect app --url https://designsystem.digital.gov/ --out ./runs \
--max-pages 40 --crawl-depth 2 --include all --include responsive.widths --sequential
curl -L -o uswds-design-kit-beta.fig https://raw.githubusercontent.com/uswds/uswds-for-designers/b2211533a79c5b2f6e6a403bd57e6ab6785e6df6/figma/uswds-design-kit-beta.fig
stage1 fig-extract ./uswds-design-kit-beta.fig --out ./fig-out
stage1 redrift RUN_DIR --fig-tokens ./fig-out/uswds-design-kit-beta.tokens.json --out ./comparison --durable
stage1 view RUN_DIR --analysis ./comparisonReplace RUN_DIR with the folder the capture prints. The kit link is pinned to a commit, so you’ll compare against the same file we did. The site changes, so your counts may not match ours.
The evidence
Every count here comes from capture e62943ea and comparison 9469226e. The October 4 revision used capture bd57ec09 and comparison 6bd1cc75. The first version used capture 00fe0602 and comparison 8ccfb02d.
It opens in any browser, with nothing to install. It holds the screenshots, accessibility results and full comparison from this run, with example elements for explained values and the exclusions and unjudged families left visible.
Your product, measured the same way
A Drift Audit does this for your product, against your pages and journeys, your Figma library, your tokens and your source. We trace each difference to its cause and walk your team through what to fix first. About two weeks.