[FEATURE] Allow onboarding to continue without Accessibility permission (clipboard fallback)

[uzairansaruzi]

Problem

Onboarding currently blocks progress until Accessibility Access is granted. The Continue button stays disabled while Accessibility shows as Needed, even when Microphone is already ready.

This is a hard stop for users who cannot or do not want to grant Accessibility—for example:

• Managed / work Macs where Accessibility is restricted by MDM or IT policy
• Personal devices where users prefer not to grant Accessibility
• Environments where auto-paste into other apps is unnecessary

Basic dictation can still be useful without Accessibility. Accessibility is mainly needed for injecting/pasting text into other apps; copying the transcript to the clipboard does not require it.

Current UI (permissions step):

• Microphone: Ready
• Accessibility Access: Needed
• Continue: disabled until Accessibility is granted

Proposed solution

1. Onboarding: Let users continue (or skip) without granting Accessibility, with clear copy that auto-paste will be unavailable until it is enabled later.
2. Runtime fallback: Without Accessibility, use a clipboard-only output mode (copy the dictated text to the clipboard) instead of failing or blocking use of the app.
3. Settings: Keep a path to enable Accessibility later (and preferably switch between auto-paste and clipboard-only when permission becomes available).

Alternatives considered

• Requiring Accessibility for all use remains a blocker on locked-down machines.
• Related: #481 proposes a “None” text insertion mode (clipboard-focused workflows). This request is specifically about not gating onboarding / basic use on Accessibility, with clipboard as the no-permission fallback.

Additional context

Accessibility should remain recommended for the full auto-type/paste experience, but it should not be a hard requirement to finish setup or use core dictation.

[uzairansaruzi]

[grohith327]

Hey @uzairansaruzi valid concern, We do have to rethink the UX of the onboarding flow though. Let them know what they are missing out when they do not provide accessibility permission.

[uzairansaruzi]

Implementation plan (research)

Addressing the hard Accessibility gate in onboarding, plus a usable clipboard-only path when Accessibility is unavailable. Aligns with @grohith327’s note: users who continue without Accessibility should clearly understand what they lose.

Current behavior (code)

Area	Behavior	Location
Onboarding Continue	Disabled until Microphone + Accessibility	OnboardingFlowView.canContinue → isPermissionsReady in Sources/Fluid/UI/WelcomeView.swift
Onboarding completion	Blocked if Accessibility missing	ContentView.missingOnboardingCompletionRequirements()
Text injection	Silent no-op when !AXIsProcessTrusted()	TypingService.typeOutputPlanInstantly
Global hotkeys	Event tap setup refuses without Accessibility	GlobalHotkeyManager.setupGlobalHotkey()
Clipboard backup	Optional (copyTranscriptionToClipboard, default false) and separate from injection	ContentView dictation finish paths + ClipboardService
Settings	Already has “enable Accessibility” CTA when hotkeys are blocked	SettingsView Global Hotkey card
Skip patterns	AI + Playground already support skip flags	SettingsStore.onboardingAISkipped / onboardingPlaygroundSkipped

Important constraint: Accessibility is required today for both auto-paste and global hotkeys (CGEvent.tapCreate with .defaultTap + explicit AXIsProcessTrusted() gate). Skipping Accessibility without a non-hotkey trigger leaves dictation mostly unusable outside the main window.

Related but separate: #481 (“None” insertion mode). This issue should not block on a full insertion-mode redesign; clipboard fallback when Accessibility is missing is enough for v1.

---

Proposed product behavior

1. Permissions step: Microphone remains required. Accessibility is recommended, not required.
2. Clear tradeoff copy (per collaborator feedback), e.g.:
   • Without Accessibility you won’t get: global hotkeys, auto-type/paste into other apps, Edit Mode selection.
   • You will get: in-app / menu-triggered dictation with transcript copied to the clipboard (paste manually with ⌘V).
3. Continue / Skip: Allow Continue when mic is ready; if Accessibility is still Needed, require an explicit secondary action (e.g. Continue without Accessibility / Skip for now) so it isn’t accidental.
4. Runtime: If Accessibility is missing at output time → copy transcript to clipboard (always), skip injection, show a brief confirmation (notch/toast) instead of silently dropping text.
5. Settings: Keep existing enable path; when Accessibility is later granted, existing polling/restart flow should restore hotkeys + insertion. Optionally remind that auto-paste is now available.

---

Implementation steps

1) Onboarding: soft-gate Accessibility

Files: Sources/Fluid/UI/WelcomeView.swift (OnboardingFlowView), optionally shared copy helpers

• Change permissions Continue gating to microphone-only.
• Add footer Skip / “Continue without Accessibility” when Accessibility is not ready (reuse cinematicFooter’s existing skipTitle/canSkip pattern used by playground).
• Update permissions copy:
  • Headline/subtitle should not imply both permissions are mandatory (“Two quick permissions…”).
  • When Needed: short callout of what is unavailable vs clipboard fallback.
• Persist skip intent, e.g. SettingsStore.onboardingAccessibilitySkipped (mirror AI/playground skip), reset in resetOnboardingProgress() / bootstrap paths.
• When skipping Accessibility, auto-enable copyTranscriptionToClipboard = true so the fallback is on by default for that install path.

2) Unblock onboarding completion

File: Sources/Fluid/ContentView.swift

• Stop treating Accessibility as a hard requirement in missingOnboardingCompletionRequirements().
• Treat skipped Accessibility + mic ready as completable.
• Keep voice model / mic / AI / playground rules as they are (playground already has Skip).

3) Playground when Accessibility was skipped

Files: WelcomeView.swift (playground step), OnboardingTryoutStepView.swift

• Onboarding tryout is hotkey-based today, so without Accessibility it can’t validate via shortcut.
• If Accessibility skipped / disabled: show an in-app Record/Stop control (same pattern as post-onboarding WelcomeView playground), or lean harder on existing Skip.
• Prefer in-app record so users can prove mic+model work without Accessibility.

4) Runtime clipboard fallback (core)

Files: TypingService.swift, ContentView.swift (dictation finish / reprocess paths), optionally notch overlay copy

• In TypingService, replace the accessibility early-return no-op with a clipboard-only path (via ClipboardService), or handle the fallback one layer up in ContentView before calling type APIs.
• Recommended policy when !AXIsProcessTrusted():
  1. Copy final transcript to clipboard.
  2. Do not attempt CGEvent / AX injection.
  3. Surface UI: “Copied to clipboard. Enable Accessibility for auto-paste / hotkeys.”
• Ensure this runs even if copyTranscriptionToClipboard was previously off (skip path should have turned it on; still harden at runtime).
• Avoid double-copy when the setting is already on.

5) Non-hotkey trigger (needed for a real “basic use” path)

Without this, finishing onboarding without Accessibility still leaves no practical system-wide capture path.

Minimum viable: Document + rely on Getting Started in-app Record button + History “copy”.

Recommended for this issue: Add Start/Stop Dictation to the menu bar menu in MenuBarManager.swift, wired to the same start/stop pipeline as ContentView.startRecording / stopAndProcessTranscription. That gives MDM / no-Accessibility users a working clipboard workflow.

Defer (not required for this issue): Input Monitoring–based hotkeys without Accessibility — larger architectural change.

6) Settings polish

File: SettingsView.swift

• Existing Accessibility CTA stays.
• When Accessibility is missing: state clearly that the app is in clipboard-only mode; keep Copy to Clipboard visible/on.
• When Accessibility becomes available: hotkey card returns to normal (existing behavior); no new mode enum required for v1.

7) Persistence / analytics (light)

File: SettingsStore.swift (+ backup payload if needed)

• Add onboardingAccessibilitySkipped (and include in reset/bootstrap).
• Optional analytics property for “accessibility_skipped_during_onboarding” / “clipboard_only_output” — only if existing analytics patterns make this cheap.

8) Tests / manual QA

• Unit/UI coverage is thin here today; prioritize manual matrix:
  • Mic granted, Accessibility denied → Continue without Accessibility works.
  • Skip copy shows tradeoffs (no hotkeys / no auto-paste).
  • Onboarding completes; copyTranscriptionToClipboard is on.
  • Menu bar (or in-app) dictation copies text; nothing is typed into other apps.
  • Enabling Accessibility later restores hotkeys + insertion (existing restart/polling).
  • Mic still required; Continue stays disabled without mic.
  • Playground: in-app record or Skip works without Accessibility.

---

Files expected to change

Priority	File	Why
P0	Sources/Fluid/UI/WelcomeView.swift	Soft-gate Continue; skip UX; permissions copy; playground alternate
P0	Sources/Fluid/ContentView.swift	Completion requirements; ensure clipboard fallback on dictation finish
P0	Sources/Fluid/Services/TypingService.swift	Don’t drop text when Accessibility missing
P0	Sources/Fluid/Persistence/SettingsStore.swift	Skip flag + default clipboard on skip
P1	Sources/Fluid/Services/MenuBarManager.swift	Start/Stop Dictation without hotkeys
P1	Sources/Fluid/UI/OnboardingTryoutStepView.swift	Optional in-app record UI when AX skipped
P1	Sources/Fluid/UI/SettingsView.swift	Clipboard-only status copy
P2	Sources/Fluid/Services/ClipboardService.swift	Only if shared helper/API needs extension
P2	Notch / overlay UI	Confirmation toast for clipboard-only output

---

Suggested PR scope / sequencing

PR 1 (this issue): soft-gate onboarding + completion + clipboard fallback + skip copy + auto-enable clipboard + menu-bar Start/Stop (or at least in-app record path).

Follow-ups (separate):

• #481 explicit “None” / clipboard-only insertion mode in Settings (even when Accessibility is granted).
• Optional Input Monitoring hotkeys without Accessibility (larger change; not needed to unblock MDM users if menu-bar trigger ships).

Open decision for implementer

Whether Continue itself becomes enabled without Accessibility, or stays disabled with a separate Continue without Accessibility button. Recommendation: separate explicit control so the recommended path stays prominent and the tradeoff is deliberate.