Skip to main content
Accessibility

Accessibility statement

Last updated · May 16, 2026

If myClipr doesn't work for you the way it should, we want to know — and we want to fix it.

Conformance target

We target WCAG 2.2 AAA on color contrast and WCAG 2.2 AA on every other success criterion. The design system was built around the heaviest possible contrast (2px ink borders, flat saturated color blocks, no shadows or gradients) precisely so AAA contrast is the floor, not the ceiling.

Contrast ratios are baked into our design tokens. Every ink-on-* color pair we ship passes ≥7:1. Body text on coral is constrained to ≥18px because that pair lands at 5.4:1, which is AAA-large but only AA-normal; the constraint is enforced in the component library, not left as a guideline.

What we've verified

  • Color contrast: every ink-on-* pair in the design system is pre-computed and verified at AAA.
  • Keyboard reachability of the marketing surface: every interactive element on the landing, manifesto, and sustainability page is reachable with the keyboard. Skip-to-main link is the first focusable element on every page.
  • Focus rings: visible focus rings (3px solid coral, 2px offset) on every :focus-visible element, scoped under .v5-root so the marketing pages and the in-app surfaces stay consistent.
  • Reduced-motion preference: the AI typing demo on the landing reads window.matchMedia("(prefers-reduced-motion: reduce)") and renders the full summary up-front instead of animating chars + tags.
  • ARIA pattern for the FAQ accordion: single-open pattern, aria-expanded + aria-controls on the button, role="region" + aria-labelledby on the panel. The pricing toggle uses role="switch" + aria-checked.
  • Semantic landmarks: <nav>, <main>, <section>, <footer> with appropriate aria labels. Each section carries an aria-labelledby pointing at its heading.

What's audited today

We run automated axe-core checks (WCAG 2.0/2.1/2.2 AA tagset) against every public page at both desktop (1280×800) and mobile (375×667) viewports. The most recent pass shows zero critical and zero serious violations across all public surfaces.

The authenticated app (dashboard, boards, projects, notes, settings) has been swept and the critical + serious findings have been addressed. The audit script lives in our build tooling and can be re-run on demand.

What's still pending

  • External screen-reader audit. Automated tooling catches a lot but not everything a sighted-vs-SR comparison surfaces. A focused NVDA + VoiceOver walkthrough by an external accessibility consultant is on the roadmap.
  • Bookmark-card interactive pattern. Cards currently use role="button" with nested buttons for the per-card actions. axe-core flags this as nested-interactive. A stretched-link refactor is queued so the card itself becomes a passive container with sibling interactive controls.

Known issues

  • The marketing page's 132px hero title overflows on viewports below 420px. Fluid sizing brings it to min(14vw, 80px) at that breakpoint; a proper mobile design is queued.
  • The hero illustration is decorative and carries aria-hidden, but the geometric placeholder may read as content to a sighted assistive tech user expecting an image. The commissioned illustration will ship with an explicit empty alt.
  • The browser extension popup has not been keyboard-audited end-to-end. The advanced-save flow uses native form controls, but tab order through the project picker has not been verified.

Standards we measure against

  • WCAG 2.2: Web Content Accessibility Guidelines, the standard the EU Accessibility Act and most national regulations adopt.
  • EN 301 549: the European harmonised standard for ICT accessibility, layered on top of WCAG 2.2.
  • ARIA Authoring Practices Guide: for interaction patterns (accordion, switch, dialog) we don't invent.

Reporting a barrier

If something on myClipr doesn't work for you, write to [email protected] with a subject line starting [a11y]. We aim to acknowledge within one working day and ship a fix or a documented workaround within ten.

If we can't fix something quickly, for example because it depends on a deeper design change, we'll say so plainly, give you a date we'll revisit, and add the issue to the "Known issues" list above so it's public.

Where this statement gets updated

When we ship a meaningful accessibility change (closing a known issue, completing an audit, finding a regression) the Last updated date at the top of this page moves and the relevant section is rewritten.

§ · Accessibility

Accessibility statement

Last updated · May 16, 2026

Conformance target

We target WCAG 2.2 AAA on color contrast and WCAG 2.2 AA on every other success criterion. The design system was built around the heaviest possible contrast (2px ink borders, flat saturated color blocks, no shadows or gradients) precisely so AAA contrast is the floor, not the ceiling.

Contrast ratios are baked into our design tokens. Every ink-on-* color pair we ship passes ≥7:1. Body text on coral is constrained to ≥18px because that pair lands at 5.4:1, which is AAA-large but only AA-normal; the constraint is enforced in the component library, not left as a guideline.

What we've verified

  • Color contrast: every ink-on-* pair in the design system is pre-computed and verified at AAA.
  • Keyboard reachability of the marketing surface: every interactive element on the landing, manifesto, and sustainability page is reachable with the keyboard. Skip-to-main link is the first focusable element on every page.
  • Focus rings: visible focus rings (3px solid coral, 2px offset) on every :focus-visible element, scoped under .v5-root so the marketing pages and the in-app surfaces stay consistent.
  • Reduced-motion preference: the AI typing demo on the landing reads window.matchMedia("(prefers-reduced-motion: reduce)") and renders the full summary up-front instead of animating chars + tags.
  • ARIA pattern for the FAQ accordion: single-open pattern, aria-expanded + aria-controls on the button, role="region" + aria-labelledby on the panel. The pricing toggle uses role="switch" + aria-checked.
  • Semantic landmarks: <nav>, <main>, <section>, <footer> with appropriate aria labels. Each section carries an aria-labelledby pointing at its heading.

What's audited today

We run automated axe-core checks (WCAG 2.0/2.1/2.2 AA tagset) against every public page at both desktop (1280×800) and mobile (375×667) viewports. The most recent pass shows zero critical and zero serious violations across all public surfaces.

The authenticated app (dashboard, boards, projects, notes, settings) has been swept and the critical + serious findings have been addressed. The audit script lives in our build tooling and can be re-run on demand.

What's still pending

  • External screen-reader audit. Automated tooling catches a lot but not everything a sighted-vs-SR comparison surfaces. A focused NVDA + VoiceOver walkthrough by an external accessibility consultant is on the roadmap.
  • Bookmark-card interactive pattern. Cards currently use role="button" with nested buttons for the per-card actions. axe-core flags this as nested-interactive. A stretched-link refactor is queued so the card itself becomes a passive container with sibling interactive controls.

Known issues

  • The marketing page's 132px hero title overflows on viewports below 420px. Fluid sizing brings it to min(14vw, 80px) at that breakpoint; a proper mobile design is queued.
  • The hero illustration is decorative and carries aria-hidden, but the geometric placeholder may read as content to a sighted assistive tech user expecting an image. The commissioned illustration will ship with an explicit empty alt.
  • The browser extension popup has not been keyboard-audited end-to-end. The advanced-save flow uses native form controls, but tab order through the project picker has not been verified.

Standards we measure against

  • WCAG 2.2: Web Content Accessibility Guidelines, the standard the EU Accessibility Act and most national regulations adopt.
  • EN 301 549: the European harmonised standard for ICT accessibility, layered on top of WCAG 2.2.
  • ARIA Authoring Practices Guide: for interaction patterns (accordion, switch, dialog) we don't invent.

Reporting a barrier

If something on myClipr doesn't work for you, write to [email protected] with a subject line starting [a11y]. We aim to acknowledge within one working day and ship a fix or a documented workaround within ten.

If we can't fix something quickly, for example because it depends on a deeper design change, we'll say so plainly, give you a date we'll revisit, and add the issue to the "Known issues" list above so it's public.

Where this statement gets updated

When we ship a meaningful accessibility change (closing a known issue, completing an audit, finding a regression) the Last updated date at the top of this page moves and the relevant section is rewritten.