Accessibility Statement

The items below describe accessibility patterns we intentionally ship in the app—not an exhaustive audit of every screen.

• Semantic HTML landmarks, a single H1 per view, and logical heading hierarchy where we have structured pages.
• Keyboard-reachable controls, visible focus styles on many interactive elements, and a skip link to main content.
• Drag-and-drop schedule reordering with an alternate keyboard path and screen-reader announcements on desktop.
• A dark-theme color system chosen for readable text and UI contrast.
• Labels and text alongside icons so key actions are not conveyed by color alone.
• Progress indicators paired with visible text labels in key flows.
• Many primary touch targets sized at 44×44 CSS pixels or larger.
• Respect for prefers-reduced-motion, prefers-contrast, and forced-colors media queries.
• A two-tap confirmation pattern for destructive actions, with screen-reader announcements.
• Auto-save status announced to screen readers in the builder.
• Print styles designed to be grayscale-friendly.

Our testing is lightweight and happens during development—we do not run a formal accessibility program or third-party evaluation.

• We use eslint-plugin-jsx-a11y lint rules in the codebase to catch common markup mistakes.
• We do brief keyboard-only checks on flows we change (tab order, focus, and activating buttons/links without a mouse).
• We do not currently hire third-party accessibility auditors, publish a VPAT, or run axe DevTools or Lighthouse accessibility gates on every release.
• We do not routinely test with screen readers such as VoiceOver or NVDA across the full product.

• The application is currently available in English only.
• Some screens or edge cases may not yet meet our WCAG 2.1 AA target; we depend on user reports to find and fix gaps.
• The Stripe checkout and customer portal are provided by a third party; Stripe maintains its own accessibility statement and we do not control that experience.