Federal UIs, accessible by default.

Why federal frontend is different

Commercial frontend engineering optimizes for conversion. Federal frontend engineering optimizes for comprehension. The user is not a paying customer — they are a veteran trying to file a disability claim at 11pm after a shift, a SNAP applicant using a library computer with a screen reader, a federal employee on an ancient managed laptop with JavaScript execution throttled by endpoint security software. The bar is: can this person, on their hardware, with their constraints, complete the task without asking for help.

We build to that bar. That means shipping semantic HTML that works without JavaScript, designing focus management that works for keyboard-only users, picking font sizes and color contrasts that meet WCAG 2.2 AA and the forthcoming WCAG 2.2 AAA where agency policy demands, and testing with the assistive technology federal users actually have — JAWS on a government Windows laptop, not the latest macOS VoiceOver build.

Framework and library stack

• React 18/19 with TypeScript 5.x — our default for federal applications. Strict TypeScript config, no implicit any, explicit return types on all exported functions. React Server Components in Next.js 15 when SEO and time-to-first-byte matter (most public-facing federal sites).
• Next.js 15 — App Router, Server Components, streaming SSR. Deploys cleanly to Cloudflare, Vercel GovCloud, or self-hosted on AWS GovCloud via standalone output. We prefer static export when the content is genuinely static; SSR when user-specific data drives the page.
• Vue 3 + Nuxt 3 — when the agency already runs Vue or when the frontend team is stronger in Vue than React. Composition API with `<script setup>`, Pinia for state, VueUse for composables.
• Svelte 5 + SvelteKit — for the smallest possible JavaScript bundle, which matters for low-bandwidth federal users (rural veterans, tribal health facilities). Runes for reactivity, zero framework runtime cost where practical.
• Astro — for content-heavy federal sites (policy documentation, program overviews, case study collections). Islands architecture ships HTML by default with JavaScript only where interactivity is required.

State management

The most common frontend sin in federal projects is over-engineered state management. A three-screen internal tool does not need Redux with ten slices and twenty thunks. We default to TanStack Query (formerly React Query) for server state — which eliminates 80% of what teams used to put in Redux — and Zustand or Jotai for the client state that remains (form drafts, UI toggles, wizard progress).

Redux Toolkit is still the right tool when the state graph is genuinely complex (a case management workbench with twenty cross-cutting concerns, a real-time ops dashboard with bidirectional sync). We use it when warranted, not by reflex. We never use plain Redux without Toolkit in new code — the ceremony overhead is no longer justified.

For forms, React Hook Form with Zod validation is our standard. It integrates cleanly with USWDS input components, supports field-level and form-level validation, and produces the error-message-association patterns (aria-describedby linking the input to its error text) that accessibility auditors expect.

USWDS and the federal design system

The U.S. Web Design System (USWDS v3) is the default design system for federal civilian agencies and the baseline every 21st Century IDEA Act site must meet. We treat it as a foundation, not a ceiling. Our pattern:

• Install @uswds/uswds as a dependency. Import its Sass source, not compiled CSS — we want access to tokens and mixins.
• Define an agency theme layer that overrides USWDS design tokens (primary color, font stack, spacing scale). Token changes ship through a versioned package so Figma and code stay in sync.
• Wrap each USWDS component in a thin React/Vue wrapper that enforces our typing, adds telemetry hooks, and — critically — applies our accessibility test harness so every usage is validated.
• Contribute upstream when we find a bug or need a pattern USWDS doesn't cover. The USWDS team is responsive and our fixes benefit every federal project.

For DoD and intelligence community work, we use the NGA/DIA federal style guides where mandated, or hybrid stacks combining Ant Design / shadcn/ui with USWDS-equivalent accessibility patterns. Every design system decision gets documented in an ADR.

Section 508 and WCAG 2.2 AA: real compliance

Section 508 of the Rehabilitation Act requires federal agencies to make their electronic and information technology accessible to people with disabilities. The technical standard is WCAG 2.1 AA (moving to 2.2 AA as agencies update their policies). Compliance is not a checkbox you tick at the end — it is an engineering discipline that has to live in the codebase.

Our approach at the component level:

• Semantic HTML first. A <button> is a button. A <nav> is navigation. We do not use <div role="button"> unless we have exhausted the semantic alternatives.
• Keyboard navigation — every interactive element reachable and operable via keyboard, with visible focus indicators that meet the WCAG 2.2 focus-not-obscured criterion.
• ARIA only when HTML can't express intent. aria-label, aria-labelledby, aria-describedby, aria-live — used surgically. No aria-hidden="true" on interactive elements.
• Color contrast — 4.5:1 for normal text, 3:1 for large text and UI components. Enforced via automated token-level tests and manual Figma audits.
• Motion and animation — honor prefers-reduced-motion. No autoplay video with audio. Transitions under 200ms or skippable.
• Forms — labels programmatically associated with inputs, error messages linked via aria-describedby, required fields marked in text not just visually, and the submit action reachable without pointer use.

At the pipeline level, every pull request runs axe-core through Playwright on every route and jest-axe on every component. The build fails on any new accessibility violation. Before release, we run manual audits with NVDA on Windows, JAWS on Windows (still the most-used screen reader in federal agencies per WebAIM's annual survey), and VoiceOver on macOS and iOS, plus keyboard-only walkthroughs. Automated tools cover about 57% of WCAG criteria — the rest requires human judgment.

Performance for federal users

Federal users are often on constrained connections: rural broadband, tribal cellular, VA health kiosks on throttled networks, DoD SIPRNet with packet inspection adding latency. We optimize for p95 network conditions, not p50:

• Initial JS budget — under 150KB gzipped for the critical path. Code splitting by route, lazy loading by interaction.
• Image strategy — next/image or equivalent with AVIF-with-WebP-fallback, explicit width/height to prevent CLS, responsive srcset.
• Fonts — system fonts when possible, WOFF2 with font-display: swap, preloaded and subsetted when agency branding demands a custom face.
• Third-party scripts — minimized. Federal analytics (DAP, agency-specific) loaded async, with no dependencies in the critical path.
• Core Web Vitals — LCP under 2.5s, INP under 200ms, CLS under 0.1 on a representative federal user profile (mid-tier Android on 3G equivalent).

Security on the frontend

Frontend security is often neglected in federal projects because it's assumed to be a backend concern. It isn't. We ship:

• A strict Content Security Policy with no unsafe-inline, no unsafe-eval, nonce-based for any unavoidable inline scripts.
• Subresource Integrity on every third-party script and style.
• X-Frame-Options and CSP frame-ancestors to prevent clickjacking of federal UIs.
• Careful handling of user-generated content: DOMPurify or equivalent for any HTML that passes through the client.
• No localStorage for authentication tokens — HttpOnly cookies or memory-only storage with silent refresh.