Tracker
Draft — not legally reviewed.These documents are placeholder text pending solicitor review and completion of the company's trading details. They do not form a binding agreement in their current state, and must not be relied on in any commercial relationship until an executed, reviewed version is published.

Accessibility Statement

Accessibility Statement

⚠ DRAFT — pending real-browser audit + manual screen-reader walkthrough. The structural fixes and the automated regression gates described below have shipped, but a full manual a11y review (keyboard-only nav across all flows + VoiceOver/NVDA spot-check) has not yet been completed. Claims marked (unverified) are intentions backed by the automated tests, not human-verified facts.

Last updated: 2026-04-23. Version: 0.1 — draft.

Our commitment

Tracker is a compliance product. A non-accessible compliance product is the same shape of failure as a security product with a 0-day, so we treat WCAG 2.1 Level AA as a baseline rather than an aspiration.

We aim to align with the European Accessibility Act, the UK Equality Act 2010 digital-accessibility expectations, and the WCAG 2.1 Level AA technical criteria.

What we've done

The current state, as of the date above:

  • Foundation — every interactive widget (buttons, dropdowns, dialogs, comboboxes) is built on Radix UI primitives, which carry keyboard navigation, focus management, and ARIA roles correctly out of the box.
  • Skip-to-main-content link on every page (WCAG 2.4.1).
  • Page landmarks — every page has <header>, <nav>, <main> in the right place; the skip link targets the main region.
  • Form labels explicitly associated via <label htmlFor> ↔ <input id> on every authentication and settings form. Errors carry role="alert", are paired with non-colour cues (icon + literal "Error:" prefix), and are linked to the relevant input via aria-describedby so screen readers announce them in context (WCAG 1.4.1, 3.3.1, 4.1.3).
  • Data tables — all tables (API tokens, members, audit log) carry an sr-only <caption> describing the table content and scope="col" / scope="row" on header cells (WCAG 1.3.1).
  • Heading hierarchy — each page has a single <h1> that reflects the page state; conditional renders consolidate to a state-dependent heading rather than multiple h1s (WCAG 2.4.6).
  • Focus indicators — visible focus-visible:ring styling on every interactive element via the shared button / input primitives. No outline-none traps without a replacement indicator (WCAG 2.4.7).
  • Automated regression gates:
    • Component-level: vitest-axe runs on every push and pins the structural patterns we use (auth-error block, data table, skip-link target, form labels). See test/component/a11y-patterns.test.tsx.
    • Browser-level: @axe-core/playwright runs against a real Chromium engine for the public pages (login, signup, forgot-password, the legal docs). See test/e2e/a11y.spec.ts. Run locally with npm run test:e2e.

Known limitations

What is not yet covered, in honest detail:

  • (unverified) Manual keyboard-only walkthrough across the full authenticated experience (dashboards, requirements / gaps / tasks flows, framework adoption, settings).
  • (unverified) Screen-reader spot-check with VoiceOver (macOS) or NVDA (Windows) on the same flows.
  • (unverified) Colour-contrast audit in dark mode beyond what the default theme contributes — custom branding combinations not yet reviewed.
  • The browser-level automated suite covers public pages only. Authenticated pages need a seeded user + sign-in flow before they can be added; queued.
  • Mobile / touch gestures not specifically tested. The application is designed for desktop-class interaction; the responsive layout works at narrow viewports but isn't optimised for screen-reader
    • touch combined navigation.
  • Live-region / dynamic-content announcements outside the auth pages have not been audited individually.

Compatibility

We test against the latest stable Chromium (the engine shared by Chrome, Edge, Brave, Arc, etc.). Firefox and Safari are expected to behave similarly because the underlying primitives are engine-agnostic, but we don't run an automated sweep against them.

The application requires JavaScript. It will not function with JS disabled.

How to report an accessibility issue

If you encounter an accessibility barrier when using Tracker, we want to hear about it. Email [ACCESSIBILITY_CONTACT_EMAIL] with:

  • The page or feature where the issue occurred (URL is helpful).
  • A description of the barrier and the assistive technology in use (e.g. "VoiceOver on Safari can't reach the Save button on the requirement-edit form").
  • Your contact details if you'd like a response.

We'll acknowledge within 5 working days and aim to ship a fix or an honest plan within 30 days, depending on scope.

Conformance status

This product partially conforms to WCAG 2.1 Level AA. Partially because of the unverified items in the Known limitations section above — we have a good automated baseline and the structural fixes to back the claim, but the manual sweep that would let us assert conforms hasn't been done yet.

This statement will move from partially conforms to conforms once the manual checklist in docs/a11y/baseline.md has been completed and signed off, and the (unverified) tags in the "What we've done" section are removed.

Standards and references

  • WCAG 2.1 Level AA — https://www.w3.org/TR/WCAG21/
  • European Accessibility Act (Directive (EU) 2019/882) — applicable scope being assessed for this product class.
  • UK Equality Act 2010 — Part 3, services and public functions; Part 4, premises; applied to digital services per UK case law.