Arcticalm

Accessibility

Last updated: May 22, 2026

Arcticalm is designed for users aged 18–80, including people who are deaf, blind, or living with other disabilities. We treat accessibility as a core requirement, not an afterthought. This page describes the standards we follow, what we've implemented, known limitations, and how to reach us if you run into a barrier.

1. Conformance Target

Arcticalm targets conformance with the Web Content Accessibility Guidelines (WCAG) 2.2, Level AA, applied to our mobile app (iOS and Android) and to this website. WCAG 2.2 is the most current published version of the guidelines as of writing.

We also align with platform-native accessibility APIs:

  • iOS — UIAccessibility (VoiceOver, Dynamic Type, Reduce Motion, Switch Control)
  • Android — AccessibilityNodeInfo (TalkBack, font scaling, high-contrast text)

This is a statement of intent and ongoing effort, not a third-party audit certificate. We continuously test against the criteria below and address gaps as they're discovered.

2. What We've Implemented

2.1 Screen reader support

  • Every interactive element exposes an explicit accessibilityRole (button, link, radio, etc.) so VoiceOver and TalkBack announce it correctly.
  • Every interactive element has a human-readable accessibilityLabel. We never rely on icon-only or symbol-only affordances.
  • Disabled, busy, checked, and expanded states are exposed via accessibilityState so screen readers can announce them accurately.
  • Non-obvious actions (expand/collapse, swipe-to-delete) carry a localized accessibilityHint.

2.2 Dynamic content announcements

Elements whose content changes over time — for example the phase label during a breathing exercise (Inhale, Hold, Exhale) — use accessibilityLiveRegion="polite" so screen readers announce the change without interrupting the user.

2.3 Visual contrast

All text and interface elements are designed to meet WCAG AA contrast ratios: 4.5:1 for body text and 3:1 for large text and meaningful UI components. We do not introduce design tokens that fall below this threshold. Dark mode is fully supported and tested independently for contrast.

2.4 Touch targets

All interactive elements are at least 44×44 points (Apple's HIG minimum). Where a visual element is smaller than that, the interactive hit area is extended via hitSlop so the user doesn't need pixel-perfect aim.

2.5 Equivalents for audio cues (Deaf users)

Every audio cue in Arcticalm has a synchronized visual equivalent:

  • Breathing pace bells are accompanied by phase animations and live-region text changes.
  • Completion bells are paired with an end-of-session screen.
  • Affirmation playback timing is reflected by the activity timer.

No information in the app is conveyed by sound alone.

2.6 Equivalents for visual cues (Blind users)

Every animation or visual rhythm in the app has an accompanying audio cue and announced text. The breathing phase, session progress, and completion state are all reachable without sight.

2.7 No motion-only signals

We respect the system Reduce Motion preference where available. The animated breathing visuals are decorative — phase information is also delivered via audio and text, so users who disable motion lose nothing functional.

2.8 Localization

Every user-facing string — including accessibility labels, hints, and screen-reader announcements — is fully translated into the three languages we support: English, French, and Spanish. No English is hardcoded in component code.

2.9 Dynamic Type and font scaling

The app respects the system text-size setting on both iOS and Android. Layouts are designed to remain usable at the largest accessible text sizes without truncation or overlap.

2.10 No login, minimal cognitive load

Arcticalm has no signup flow, no account recovery, and no password to remember. The user journey from launch to a completed session is deliberately short. This is partly a privacy decision and partly an accessibility decision — fewer steps means fewer opportunities for friction.

3. Compatibility

The Arcticalm mobile app has been built and tested against:

  • iOS VoiceOver on iOS 17 and later
  • Android TalkBack on Android 12 and later
  • System Dark Mode and Light Mode on both platforms
  • System font scaling (Dynamic Type on iOS, font size on Android)

This website (arcticalm.com) has been built and tested against current versions of Safari, Chrome, Firefox, and Edge on desktop and mobile, with screen-reader testing in VoiceOver (macOS) and NVDA (Windows).

4. Known Limitations

We aim to be honest about where we fall short. Current known limitations:

  • Breathing exercises require the screen to be unlocked. We use Keep Awake to prevent auto-lock during a session, but if a user manually locks the phone mid-session, JavaScript on the device is suspended and audio cues stop firing. Background audio (such as ambient sounds) continues. We're investigating native scheduling so interval audio can survive a manual lock in a future release.
  • Affirmation recordings rely on the device microphone. Users without microphone access (hardware fault, permission denied) cannot use the Affirmation Meditation feature. Every other activity in the app remains fully accessible.
  • Color-only emphasis in some charts. The Log tab uses color to differentiate activity categories. Category names are also spelled out, but at very small chart sizes the color is the primary cue. We're planning a pattern/shape addition for an upcoming update.

5. How We Test

  • Manual screen-reader walkthroughs on every new screen before release (VoiceOver and TalkBack).
  • Automated lint rules that reject interactive elements missing accessibility props.
  • Translation-key parity checks in continuous integration so localized accessibility labels never silently fall back to English.
  • Periodic contrast audits of all design tokens.

6. Reporting an Accessibility Issue

If something in the app or on this website is hard to use, broken with a screen reader, or fails any of the criteria above, we want to know. Please email us with:

  • What you were trying to do
  • What happened (or didn't)
  • Your device, OS version, and assistive technology (if applicable)

We aim to respond within 5 business days and to fix or document confirmed accessibility issues in the next available release.

7. Updates to This Statement

We will revise this page when we make material accessibility improvements or discover new limitations. The "Last updated" date at the top of this page reflects the most recent revision.