Accessibility / current approach

The decision should remain legible without a preferred device or input.

The interface is designed for keyboard, touch, screen-reader, zoom, reduced-motion, and print use across the core workflows.

01 / Supported behavior

Structure, focus, contrast, and input clarity come first.

  • Skip link and semantic landmarks
  • Visible keyboard focus
  • Programmatic labels and fieldsets
  • Live result announcements
  • Reduced-motion preference
  • Printable result layouts

02 / Current checks

Automated checks support, but do not replace, human testing.

Production builds run strict TypeScript, semantic accessibility lint, route rendering tests, calculation tests, and targeted color-contrast checks. Core controls use touch targets and responsive layouts.

03 / Known limits

No independent accessibility conformance audit is claimed yet.

Browser, assistive-technology, and real-user coverage will continue during public beta. External destinations such as government and program-owner sites have their own accessibility behavior.

04 / Feedback

Describe the page, control, device, and expected outcome.

During public beta, report a barrier to the site owner through the channel that provided access. Avoid sharing sensitive household or contractor information in the report.