Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

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

Open
  • Is something wrong?
#627 4 comments 1 reaction 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

  • #629 by @uzairansaruzi — closed without merging

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
30/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Stale
Tech stack
macos, swift
Domain
desktop, desktop-dev

Research direction

Start by reading the existing onboarding permissions flow, Accessibility-dependent text insertion behavior, and settings path for permissions; the issue does not name files or tests. Define how onboarding can continue without Accessibility and how runtime dictation uses clipboard-only output in that state. Done means users can finish setup and dictate without Accessibility, see that auto-paste is unavailable, and can enable Accessibility later.

Written by the indexing model from the issue text.

Description

stale
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.

Dominant language
Swift
Stars
11.9k
Forks
863
Avg merge
1d 13h
Merged PRs (30d)
27

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from altic-dev/FluidVoice

All issues in altic-dev/FluidVoice

Similar issues

More Swift issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.