All articles
TechnicalBy Logan Nathan · Oct 2026 · 11 min read

The Federal Design System Behind Your Site Just Changed How It Tests for Accessibility

USWDS sits underneath a lot of state and local government websites. In October 2026, the team running it started shifting toward automated accessibility testing. That happened upstream of you. Nobody asked your IT director first.

A lot of government web teams never touch the U.S. Web Design System directly. They inherit it through a theme, a CMS starter kit, or a component library someone picked three redesigns ago. That's fine, until the thing you inherited changes how it decides what counts as accessible. This month, it did.

1What Actually Changed, and When

Quick timeline, because the dates matter more than the drama. DOJ's Title II final rule set WCAG 2.1 AA as the bar back in April 2024. The April 2026 interim rule pushed compliance dates to April 26, 2027 for larger jurisdictions and April 26, 2028 for smaller ones and special districts. Neither of those changed the testing question. What changed in October 2026 is narrower and, for a lot of teams, more relevant day to day.

The group maintaining USWDS started moving its own accessibility testing process toward automation. Less manual review in the pipeline than before. A separate group of technologists, worried that automated checks alone can't catch things like screen reader traps or bad reading order, started standing up a parallel, manually-reviewed fork of the same design system. Two versions of the same component library, tested two different ways. That's the part worth paying attention to, not the politics around who proposed it.

2Why This Matters Even If You've Never Heard of USWDS

Here's the thing a lot of procurement paperwork gets wrong. A component library passing its own internal test tells you the library passed a test. It doesn't tell you your specific page, built on your specific CMS, with your specific markup wrapped around that component, passes anything.

We see this constantly in PDF remediationtoo. The pattern repeats everywhere: a thing that's accessible in isolation gets dropped into a real page and picks up a focus trap from the modal it's inside, or loses its label when a theme overrides the markup. An accordion component that passed every automated check at the source can still fail on your site if your theme strips the ARIA attributes during build. The library isn't lying. Your implementation is just a different thing than what got tested.

3What USWDS Actually Provides, for Teams Who Inherited It

If you've never had a reason to learn this, here's the short version. USWDS is a free, GSA-maintained library of pre-built interface pieces: headers, banners, accordions, form fields, date pickers, pagination, the boring plumbing every government site needs and almost nobody wants to build from scratch. It ships with accessibility baked in as a selling point, which is exactly why so many state and local CMS vendors built their default themes on top of it instead of writing their own components.

That adoption path matters here. A city that never heard of USWDS by name can still be running dozens of its components today, repackaged inside a Drupal theme or a WordPress starter kit three layers removed from the original source. A CMS built to test its own rendered output, rather than trust an upstream library's claims, is the difference between finding this out from an investigator and finding it out yourself. If you're on one of those platforms, this change is already yours whether you clicked anything or not.

4What Automated Testing Catches, and What It Quietly Skips

Automated accessibility scanners are genuinely good at a specific list of things: missing alt attributes, empty form labels, contrast ratios that fall below threshold, a missing document language attribute. All real. All worth catching early. None of that is the hard part of accessibility testing, and that's the detail that gets lost whenever a testing process shifts toward more automation.

Here's what a scanner can't tell you. Whether a keyboard focus trap exists inside a modal. Whether a screen reader announces a dropdown's expanded state correctly. Whether the reading order makes sense once a component sits inside someone else's page layout instead of a clean test harness. Specialists in this field routinely estimate that automated tools surface somewhere between a third and half of real WCAG failures, and the remainder only shows up when a person actually uses the thing with a keyboard or a screen reader running. Section 508's own guidance has historically assumed a human is in that loop. A testing pipeline that leans harder on automation isn't wrong to use it. It's just now carrying more weight than that category of tool was ever built to hold alone.

Three steps: identify which USWDS components you use, run your own keyboard and screen reader pass, date and file the test as your evidence

5Three Things to Verify on Your Own Site This Month

Don't wait for official guidance on how the USWDS change shakes out. None of this depends on it.

Identify what you actually use

Pull up your theme or CMS starter kit and list every USWDS-sourced component actually rendering on your live site: banners, accordions, form fields, date pickers. Not the full library. Just what you shipped.

Test it yourself, by hand

Tab through each one with no mouse. Turn on a screen reader and listen to it. Don't trust an upstream badge to answer a question about your own rendered page.

Date it and keep it

Write down what you tested, when, and what you found. A dated internal record is worth more in a complaint response than a reference to someone else's test results.

See What Your Rendered Pages Actually Pass

WPPersona tests your live site as built, not the component library it borrowed from. Your IT director gets a dated report, not someone else's badge.

Schedule a 15-Minute Demo

6What the Parallel Fork Effort Actually Signals

A group of technologists standing up a separately governed, manually-tested copy of the same design system isn't a small gesture. Forking a federal code base takes real time and real coordination, and people don't spend that kind of effort over a disagreement they consider minor. Read it as a signal, not a verdict: enough practitioners who work in this space daily thought the change was worth building an alternative around.

It also means two versions of the same component library may drift apart over time, accumulating their own separate bug histories and their own separate fixes. If your theme or CMS starter kit pulls from USWDS, find out which lineage it actually tracks, and don't assume the answer stays the same at your next platform upgrade.

7The Trap: Treating an Upstream Badge as Your Compliance Record

DOJ doesn't evaluate your site by asking what library you built it with. It evaluates the page a resident actually loaded. "We used a federally maintained component library" isn't a defense if the rendered form on your site has no label. It's a detail the complaint investigator will note on the way to looking at your actual markup.

Component libraries also keep changing. A theme update six months from now could quietly break something that works today, and an upstream regression test tuned to the library's own components won't always catch a context-specific failure on your implementation. Treat any shared component as a starting point you still have to test, not a finished answer you get to skip.

8A Checklist for Any Shared Component Library, Not Just This One

USWDS won't be the last upstream library to change how it tests itself. The habit that protects you applies to whatever you're building on next year too, and it pairs well with our 47-item launch checklist if you want the full pre-launch picture, not just the component layer.

  • Know which version of a shared library your theme actually pulls from, and whether it updates automatically.
  • Test the rendered component on your own site after every theme or platform update, not just at launch.
  • Keep your own dated test record independent of whatever the upstream project claims about itself.

Final Takeaway

Use whatever component library makes sense for your team. Just test what you actually shipped, not what someone else certified upstream. That habit survives every future change to USWDS, whoever's running it and however they're testing it.

Related Articles