Accessibility Statement

Our commitment

We're committed to making OverlayRiskWitness perceivable, operable, understandable, and robust for every person who uses it — regardless of the assistive technology or input method they rely on. That commitment covers the marketing site, the product application, the public evidence packets, and all transactional communications we send.

Accessibility is continuous work, not a one-time checklist. When we find a gap, we fix it. When you find one, we want to hear about it.

We do not use an accessibility overlay

Instead, we build accessibility directly into the HTML, CSS, and interaction patterns of the product from the start. Semantic markup, keyboard operability, and sufficient contrast are not patch-work additions — they are part of the initial build, reviewed on every meaningful change.

This is a deliberate, public-facing engineering and ethics position. We think it matters that the tool you use to audit overlay claims is not itself dependent on one.

Conformance target and implemented measures

Our target is WCAG 2.1 Level AA conformance across all pages and interactive features. The measures below are in place today and tested on every build.

• Semantic HTML

  Pages use the correct landmark elements (header, main, nav, footer), a logical heading hierarchy, and native interactive elements (button, a, input) rather than presentational divs with click handlers.

• Full keyboard operability

  Every interactive element is reachable and operable by keyboard alone. Tab order follows reading order. Custom components (dropdowns, modals, accordion FAQs) respect ARIA authoring patterns and support Escape, Enter, and arrow-key navigation where applicable.

• Visible focus indicators

  Focus rings are never suppressed globally. All focusable elements display a clearly visible focus indicator with sufficient contrast against the surrounding background, meeting the WCAG 2.2 Focus Appearance criteria.

• Color contrast and text sizing

  Body text (#262626 on #f9f9f9) and all interface text meet WCAG AA contrast ratios. The exhibit amber accent (#C2410C) is used sparingly and never as the sole means of conveying information. Text can be resized to 200% without loss of content or functionality.

• Alternative text and non-text content

  All meaningful images carry descriptive alt text. Decorative images use alt="" and aria-hidden="true". Evidence screenshots inside witness packets carry per-exhibit descriptions that convey the finding without relying on the image.

• ARIA — used sparingly

  We follow the first rule of ARIA: native HTML is preferred wherever it does the job. ARIA roles, states, and properties are added only where a native element cannot communicate the necessary semantics — and only after verifying the pattern with a screen reader.

• Testing

  We test with axe-core (automated) and with real assistive technology — VoiceOver on macOS / iOS and NVDA on Windows — on flows covering sign-up, witness scan submission, packet review, and checkout. Automated checks run in CI on every pull request.

Known limitations

We aim for honesty here. The following areas are under active improvement or carry constraints outside our direct control:

• Third-party embeds. Stripe's checkout iframe, Supabase Auth UI, and some analytics scripts are third-party content we cannot fully control. We choose and configure vendors that publish their own accessibility commitments, and we raise issues with them when we find gaps.
• Evidence packet PDFs. The generated PDF evidence packets are machine-readable but have not yet been fully tested with PDF accessibility workflows. Tagged PDF support is on the roadmap for the next major packet format revision.
• Data-heavy tables in the dashboard. Some comparison tables in the drift monitor view have complex column structures that may not map cleanly to all screen reader table navigation modes. We're iterating on the markup and adding explicit column headers and caption elements.
• Live-update notifications. Real-time scan progress updates use a status region, but the verbosity level and announcement timing are still being refined based on screen reader testing.

If you encounter an issue not listed here, please report it — see below.

How to report an accessibility problem

If you encounter a barrier on any part of OverlayRiskWitness, we want to know about it. Please describe what you were trying to do, the page or feature involved, and the assistive technology or browser you were using if you know it.

If you need content in an alternative format while we work on a fix — for example, the text of an evidence packet that's currently image-only — let us know in the same email and we'll provide it promptly.