CRMish

Accessibility Statement

Effective date: 2026-05-28 · DRAFT v4 — internal review pending

> Notice to readers. This document reflects our current accessibility commitments and known gaps. It is not legal advice and has not yet been audited by an external accessibility consultant. We will update it as we close gaps and as additional commitments are made.

1. Our commitment

CRMish believes that the web should be usable by everyone, regardless of ability or technology. We work to make our application — at https://crmish.io and (when launched) https://crmish.app — accessible to as wide an audience as practical, including people who use assistive technologies such as screen readers, screen magnifiers, voice control, and keyboard-only navigation.

We treat accessibility as part of product quality, not a separate workstream. New features are designed and reviewed with accessibility in mind from the start.

2. Standard we target

We target Web Content Accessibility Guidelines (WCAG) 2.1 Level AA as our conformance goal. WCAG 2.1 was developed by the World Wide Web Consortium (W3C) and is the widely-recognized benchmark for web accessibility.

We are also designing toward WCAG 2.2 Level AA as that standard's adoption grows.

3. Conformance status

Status: CRMish is partially conformant with WCAG 2.1 Level AA. "Partially conformant" means that some parts of the content do not yet fully conform.

We are actively working toward full conformance and will update this statement as we make progress. We do not currently hold a third-party WCAG audit certificate; a formal audit is planned before our first paid public launch.

4. Measures we have taken

| Area | Measure | |---|---| | Color and contrast | We use a high-contrast neutral palette with a violet accent. Text on background meets WCAG AA contrast in most surfaces. | | Keyboard navigation | All interactive elements are reachable by keyboard. Focus rings are visible. | | Semantic HTML | We use native HTML elements (<button>, <a>, <label>, <input>) rather than generic divs wherever practical, so screen readers can announce roles correctly. | | Forms | Inputs are paired with <label> elements. Required and invalid states are conveyed both visually and via aria-invalid / aria-describedby. | | Alt text | Decorative images use empty alt or aria-hidden. Meaningful images carry descriptive alt text. | | Headings | Pages use a single H1 followed by a logical heading hierarchy. | | Skip links | The main app shell includes a skip-to-content link for keyboard users. | | Time-sensitive UIs | Where modals auto-dismiss (e.g., toasts), we provide accessible names and avoid critical interactions inside ephemeral surfaces. | | Motion | We respect prefers-reduced-motion for any non-essential animation, including the Greedy-mode animations on the Today's Bar. | | Language | The HTML document declares lang="en". | | Responsive layout | The app is designed mobile-first. Content reflows at common breakpoints and supports browser zoom up to 200% without loss of content. |

5. Known limitations

We are honest about where we are not yet conformant. The list below reflects our awareness as of the effective date and is not exhaustive. We are working to address each item.

1. Mobile-responsive polish pass is in progress. Some desktop-first surfaces (notably /master, parts of /performance, the Locked 5 weekly modal) may have small-screen layout issues that affect users on narrow viewports. 2. Screen-reader testing is incomplete on newer surfaces. Features shipped in the 2026-05-26 build (Daily Drop, Sacred Hours, Coach Mode Sprint, the cross-feature push wiring, webhook integrations panel, public Track Record profile editor) have not yet been fully tested with VoiceOver and NVDA end-to-end. We expect to complete this pass within 60 days. 3. Color is occasionally the sole carrier of state. Some progress indicators rely on color (red / yellow / green tints) without an accompanying icon or text label. We are migrating these to dual-cue patterns. 4. PDF and exported documents are not yet guaranteed accessible. CSV exports are accessible by their nature. We do not currently produce PDFs. 5. Third-party embeds. Stripe Checkout, Cloudflare Turnstile, and the Anthropic-powered AI coaching responses are rendered by third parties whose accessibility we do not directly control. We pick vendors who themselves target WCAG AA. 6. Captions / transcripts. We do not currently embed video. If we add video in marketing pages, we will provide captions and transcripts.

6. How we test

| Method | When | |---|---| | Automated checks (axe-core via Playwright) | Continuous on every CI run (planned — currently manual) | | Manual keyboard-only walkthrough | At feature-ship time | | Screen-reader spot-check (VoiceOver on macOS / iOS, NVDA on Windows) | At feature-ship time on major flows | | Browser zoom test (up to 200%) | At feature-ship time | | prefers-reduced-motion test | Whenever we add animation | | Color-contrast audit | Whenever we add a color or update a palette token |

A formal external WCAG 2.1 AA audit is planned before our first paid public launch.

7. Browser and assistive-technology support

CRMish is designed to work with current versions (within the last 12 months) of:

  • Browsers: Chrome, Edge, Firefox, Safari on desktop and mobile.
  • Screen readers: VoiceOver (macOS, iOS), NVDA (Windows), TalkBack (Android), JAWS (Windows — best-effort).
  • Voice control: Voice Control (macOS, iOS), Dragon NaturallySpeaking (best-effort).
  • Magnifiers: Zoom (macOS), Magnifier (Windows), browser zoom up to 200%.

We test on the most-recent major version of each. Earlier versions may work but are not formally supported.

8. Feedback — talk to us

If you encounter an accessibility barrier on CRMish, please tell us. We take these reports seriously and will respond within 5 business days.

| What | Where | |---|---| | Report an accessibility issue | accessibility@crmish.io | | General support | support@crmish.io | | Mailing address | JAS Operations LLC dba CRMish · (to be added) |

Please include:

1. A description of the barrier. 2. The page URL where it occurred. 3. The browser, operating system, and assistive technology you were using. 4. Whether you have a workaround.

We may follow up to ask clarifying questions or to invite you to test a fix.

9. Enforcement procedures

This statement is intended to comply with the principles of the Americans with Disabilities Act (ADA), Section 508 of the Rehabilitation Act, EN 301 549 (European harmonized standard), and AODA (Ontario), insofar as those frameworks apply to a privately-operated SaaS product.

If you believe we have not adequately addressed an accessibility concern, you may contact the appropriate regulator in your jurisdiction. We would prefer to work with you directly first; see §8.

10. Date and approval

| Item | Value | |---|---| | Statement created | 2026-05-28 | | Statement effective | 2026-05-28 | | Standard targeted | WCAG 2.1 Level AA (moving toward 2.2 AA) | | Conformance level | Partial — see §5 | | Next planned review | 2026-08-28 (quarterly) | | Approval | (pending Junior + counsel review) |

Document version: accessibility-v1 · Last updated 2026-05-28.