Phase 1 merged — requesting macOS test build for VoiceOver verification

First, thank you @ten9876 for merging #899 so quickly. Getting the Phase 1 metadata pass into main within a day of the original report is genuinely extraordinary, and it gives us a real foundation to build Phase 2 on top of.

I also want to thank @m13v for the drive-by expertise on #870 — the NSAccessibilityElement / accessibilityChildren approach you described is exactly right for the custom-drawn widgets in this codebase (SpectrumWidget, VfoWidget, SMeterWidget, HGauge, RelayBar, FilterPassbandWidget, PhaseKnob, MeterSlider, KeyboardMapWidget). Qt's QAccessibleInterface is the portable way to express that tree, and on macOS it gets bridged into exactly the NSAccessibility structure you outlined — so your advice maps directly onto the Phase 2 plan. I'd love to have you review that PR when it lands.

Why I'm opening this before scoping Phase 2

I want to VoiceOver-test the merged Phase 1 before we write Phase 2, for two reasons:

1. Ground truth beats theory. A real test pass will tell us which setAccessibleName additions are actually reaching VoiceOver on macOS and which are being dropped somewhere in the Qt → QAccessibleInterface → NSAccessibility bridge. That turns Phase 2 from a guess into a targeted fix list.
2. m13v's point about custom widgets is load-bearing. If the panadapter, S-meter, VFO tab bar, and filter passband are silent under VoiceOver even after Phase 1 (which I expect they will be, because Phase 1 only touched standard controls), that confirms the Phase 2 scope: real QAccessibleInterface implementations for each custom widget, plus the VfoWidget tab bar structural fix I mentioned on macOS build is not accessible with VoiceOver #870.

I'd rather file a Phase 2 issue that says "here are the 12 specific controls that don't announce, here's what they should announce, here's the tab order problem I hit between RxApplet and TxApplet" than one that just re-lists the widget inventory in the abstract.

The ask

Could I get a macOS build of main post-#899 merge to test against? Any of these would work, in order of preference:

1. A signed .app or .dmg attached to a GitHub release or this issue — fastest for me, and also lets other blind users try it.
2. An unsigned .app.tar.gz (I'm happy to xattr -dr com.apple.quarantine it locally).
3. Build instructions for Apple Silicon (Qt6 version, any special CMake flags, fftw/homebrew prerequisites) — I can build it myself; I already maintain a Qt/C++ fork of wfview locally, so the toolchain is in place.

Once I have a build, I'll do a structured pass with VoiceOver and report back in this issue with:

• Per-control announcement quality (what VoiceOver reads vs. what it should read)
• Tab-order trace through the whole main window
• Specific controls that are silent or stuck
• Any place a user can get "lost" with no way back to a known element

From there we can scope Phase 2 concretely — custom QAccessibleInterface implementations, the VfoWidget tab bar structural fix, the master-meter live-region shortcut, focus policy, and docs/ACCESSIBILITY.md.

Thanks again to both of you. This is moving faster than I dared hope.

— AI5OS (@w9fyi)