History: double-click and ⌘C to copy an entry (accessibility) — continuing from #566

[Fe2-O3]

Moving this over from #566 at @grohith327's suggestion, so there's a proper place to discuss it. Context: issue #566, PR #568 (implemented), companion issue #567.

Why this matters to me

I'm disabled. FluidVoice has become essential to how I work: I'm usually multitasking — dictating, then copying and pasting a lot of those transcriptions back out into different apps. Just keeping the selections straight is hard enough; aiming precisely at the small Copy button on top of it is genuinely difficult for me. Being able to spot the entry I want and just double-click it is the difference between this being comfortable and being painful.

I'm running my own build from source to keep it — which means going without Fluid Intelligence entirely, since it isn't compiled into a build from this repo. I'd rather not be maintaining a fork, which is why I'd like to find a version of this that works for everyone.

What's proposed

In Activity → History:

1. Double-click a row → copies that entry's transcription.
2. ⌘C with a row selected → copies it.
3. ↑ / ↓ move the selection within the list once it's focused (previously the arrows drove the sidebar) — this is Activity → History: keyboard support for the entry list (↑/↓ navigation + ⌘C to copy) #567, which @grohith327 has already said is useful.
4. Copy confirmation on every path — the buttons flip to an inline ✓ Copied state; the gesture and keyboard paths show a small confirmation at the cursor.

All copy paths were also harmonized onto the existing clipboardText selection introduced in #450 — the same text the Copy Last Transcript menu action already uses — so double-click, ⌘C, the Copy button and the right-click menu all copy exactly the same thing. That fixed a real bug on the way: the Copy button previously copied raw processedText, which for a transcription with no AI text put an empty string on the clipboard.

The double-click question

This History view is, in practice, a clipboard-history list — not always the system clipboard, but the same concept: a list of past outputs you reach back into and re-copy. "Double-click a row to copy it" is how established macOS clipboard tools already work — Pastebot ("To copy a clipping, double-click on a clipping, or hit the return key") and Paste both bind copy to double-click; Maccy, Raycast and Alfred all re-copy on a single row activation. Requiring a double-click is, if anything, the cautious version of that pattern.

On accidental double-taps (the main concern raised): that's fair, and I don't want to wave it away. My preference is on-by-default since that's the accessible default, but gating it behind a setting is a clean compromise — zero risk for anyone who opts out.

To be clear about where this came from: double-click is an accessibility-inspired option. I didn't add it as a power-user shortcut and then reach for an accessibility justification — it exists because of a specific disability need, and I want to be precise about which one.

The comparison that matters isn't double-click vs. single-click. It's double-click on a full-width row vs. travelling the pointer to another pane and landing precisely on a small button. For me the second one is the hard part — the acquisition, not the clicking. A full-width, already-highlighted row is a large forgiving target; WCAG 2.2 SC 2.5.8 is explicit that target size is "also useful for mouse or pen users" and names "hand tremors, spasticity, and quadriplegia". That's the need this serves.

I'll be straight about the limit of the claim, because I'd rather you trust the rest of it: double-click isn't the right path for every motor impairment. Someone whose difficulty is holding the pointer steady through a click, rather than getting to the target, isn't helped by it — macOS itself lists double-click under Accessibility → Pointer Control → Alternate pointer actions, as an action it provides assistive routes to produce. So I'm not claiming it's a universal accessibility win.

That's exactly why it's an option, not a replacement. Nothing is taken away: the Copy button stays, the context menu stays, ⌘C is added for keyboard and VoiceOver users, and double-click serves pointer users for whom small-target acquisition is the barrier. As Microsoft's inclusive design guidance puts it, "Designing inclusively doesn't mean you're making one thing for all people. You're designing a diversity of ways for everyone to participate." Different impairments need different paths — that's the whole argument, and it's also why "there's already a Copy button" doesn't close it. For me, that button is the barrier.

The keyboard path is the one I'd ask you to weigh most

Right now the copy lives on .simultaneousGesture(TapGesture(count: 2)) rather than the row Button's action, so VoiceOver's activate can't reach it — ⌘C is currently the only VoiceOver-reachable way to copy a history row. That's the shape W3C documents as failure technique F54 — "using only pointing-device-specific event handlers… for a function" — against SC 2.1.1 Keyboard, which is Level A, and whose Note 1 says it "relates to the underlying function, not the input technique." Double-click is the technique; copy is the function. We're a native app, so WCAG applies by adoption rather than jurisdiction — I'm citing the principle, not asserting a violation. Note 2 is explicit that pointer input is welcome "in addition to keyboard operation," so the double-click doesn't threaten anything.

Related, and worth its own thread if you'd prefer: the app has no VoiceOver announcements anywhere, so the copy confirmation is visual-only — a VoiceOver user gets no feedback that a copy landed, by any path. I'd happily add an announcement, plus an .isSelected trait on the rows (matching the pattern already in CustomDictionaryView.swift) so VoiceOver users can tell which entry ⌘C will copy.

Where it stands

#568 is implemented and green, with the inline ✓ Copied button state built as requested. Happy to reshape any of it — split the keyboard half from the gesture half, put double-click behind a setting, or land just the pieces you're comfortable with. Mostly I'd like this to end up in the app rather than in my fork.