Summary

The macOS build of AetherSDR (tested with the universal DMG from Releases) is not usable with VoiceOver, Apple's built-in screen reader. As a blind ham, I cannot operate the application at all — VoiceOver cannot navigate the UI, identify controls, or read state from the panadapter, slice controls, meters, or menus.

Environment

• App version: 0.8.4 (latest release as of filing)
• Platform: macOS (Apple Silicon), VoiceOver enabled
• Radio: FlexRadio FLEX-8400 (not relevant to the accessibility issue, but for context)

What I observe

When VoiceOver is running and I launch AetherSDR:

• VoiceOver does not announce most controls by name or role. Buttons, sliders, combo boxes, and menu items either read as generic "group" / "unknown" or are skipped entirely.
• VO+arrow navigation does not reach many on-screen controls — large parts of the interface are invisible to the accessibility tree.
• The panadapter, waterfall, and meters are pure custom-drawn widgets with no accessible text alternative, so there is no way to know frequency, mode, S-meter reading, SWR, etc.
• Slice controls (frequency, mode, filter, AGC, NR, etc.) cannot be reached or adjusted from the keyboard with VoiceOver active.
• Dialogs and menus do not appear to expose proper accessible Name / Role / Value to the macOS Accessibility API (NSAccessibility / AX).

The net effect is that the app is unusable for blind operators on macOS today.

Why this matters

There is a real and active community of blind amateur radio operators who use FlexRadio gear. On macOS we currently rely on apps like FlexAccess and SmartSDR-via-VM workarounds because the native FlexRadio tooling is largely inaccessible. A native, open-source, Qt6 client like AetherSDR is exactly the kind of project that could finally give us first-class access — but only if VoiceOver can see the controls.

Qt6 accessibility background

Qt6 on macOS bridges QAccessible to NSAccessibility automatically, but only when widgets expose proper accessible properties. Common gaps that break VoiceOver in Qt apps:

• Custom QWidget / QQuickItem subclasses without a QAccessibleInterface implementation (panadapter, waterfall, meters, S-meter, SWR gauge, etc.).
• Controls missing setAccessibleName() / setAccessibleDescription() — VoiceOver then reads the class name or nothing.
• Icon-only QToolButtons without accessible names.
• QComboBox / QSpinBox / custom dial widgets that don't report a role or current value.
• Modal dialogs that don't set a window title or accessible name, so VoiceOver loses context when they open.
• Focus order not matching visual order, or focus getting trapped in non-focusable custom widgets.

For purely visual elements (panadapter, waterfall), the accepted pattern is to expose a textual alternative — e.g. an accessible description that announces center frequency, span, and any selected slice's frequency/mode, plus keyboard shortcuts to query meter values on demand.

What would help

In rough priority order:

1. Audit every interactive control for accessibleName / accessibleDescription and a sensible QAccessible::Role. Icon-only buttons are the highest-impact fix.
2. Make all controls keyboard-reachable (Tab / Shift+Tab) in a logical order, and ensure focus is visible to AT even when the visual focus ring is custom-drawn.
3. Custom widgets (panadapter, waterfall, meters, gauges, dial knobs) need a QAccessibleInterface subclass that reports role, current value, and a text representation. Even a simple "Panadapter, center 14.074 MHz, span 100 kHz, slice A on 14.074000 MHz USB" string would be transformative.
4. Dialogs and menus — set window titles, ensure menu items have accessible names, and verify VoiceOver focus lands inside the dialog when it opens.
5. Live regions / announcements for state changes that matter to operators: TX on/off, ATU tuning, SWR alarms, connection status, slice mode changes. Qt exposes this via QAccessible::updateAccessibility() with QAccessible::Alert / QAccessible::ValueChanged events.
6. Document keyboard shortcuts in the README / docs so screen reader users have a fighting chance even before the full audit lands.

Testing

I'm happy to test builds against VoiceOver on macOS 14/15 (Apple Silicon) and provide specific feedback on any control or screen as fixes land. If it helps, I can also provide a prioritized list of which controls are most critical for actually operating the radio (slice frequency, mode, filter, AGC, NR, TX/MOX, ATU, meters) versus nice-to-haves.

Thanks for building an open, native, cross-platform Flex client — please consider VoiceOver / NSAccessibility a first-class target on the macOS build.

73,
AI5OS