[ten9876]

Summary

Closes #6257. Related to #4896.

The ten click-handled status-bar indicators (band stack, +PAN, TNF, CWX, ASR, DVK, FDX, TUN, AMP and TX) were QLabels, or containers of labels, that only a mouse could use. That's the interactive-QLabel anti-pattern in docs/a11y.md.

A new StatusIndicator helper (src/gui/StatusIndicator.{h,cpp}) is attached to each indicator:

• Tab reaches it. Focus is Qt::TabFocus, so a mouse click still doesn't take focus. Disabled indicators stay out of the Tab order, as Qt does.
• Return or Enter runs its action, once per press; auto-repeat from a held key is ignored.
• Space is left to PTT. MainWindow's app-wide filter binds Space to PTT (Hold), and it runs before any widget's filter. So with a radio connected, Space keys PTT on a focused indicator exactly as it does on every other button. The helper never claims Space.
• Screen readers see a Button with a Press action. TNF, FDX, CWX, ASR, DVK and the band stack are checkable buttons, and they report on/off state wherever the UI restyles them, so the state isn't carried by colour alone. TUN and AMP lead their accessible description with their state word (OPERATE, BYPASS, STANDBY).
• It still works if a screen reader is already running. Naming an indicator then makes Qt cache a plain-text interface first. The helper retires it (ObjectDestroyed), and the next query builds the Button (ObjectCreated).
• Focus mark: a 2 px color.canon.cyan underline while it has keyboard focus. It's a child bar, not a stylesheet rule, because the indicators restyle themselves with whole-sheet setStyleSheet() calls.

One action path. MainWindow::activateStatusIndicator() holds the ten actions, moved verbatim from the event filter's press branches, so mouse and keyboard run the same code. TX still answers only the left mouse button. The ASR indicator is compared only under AETHER_ASR_ENABLED, which check-windows builds without.

Accessible names were added to band stack, TNF, CWX, ASR and FDX. The other five already had them.

Maintainer rulings:

• all ten indicators
• keep them as QLabels with a helper, rather than converting them to buttons
• a cyan underline as the focus mark
• Return/Enter, with Space left to PTT
• report on/off state
• one shared mouse/keyboard dispatcher
• disabled indicators stay out of the Tab order
• accept the new ThemeManager.h include

Constitution principle honored

Principle VI. A focused status indicator never turns Space into anything but the PTT behaviour every other button already has. A test pins it behind the real PTT decision.

Test plan

• status_indicator_test (33 cases, offscreen):
  • Tab focus policy
  • Return/Enter activate; Space, other keys, auto-repeat and a disabled indicator don't
  • Button role, name, and a Press action that activates
  • a container of labels activates the same way, and its inner labels stay plain text
  • checkable state, with one StateChanged per real change
  • when accessibility is already active: interface replacement, with ObjectDestroyed before ObjectCreated
  • underline placement, visibility and focus behaviour
  • behind an app-level filter running the real pttHoldKeyStep() with a radio connected: Space on a focused indicator is PTT and doesn't activate it; Return activates it and keys nothing
• Checked by inverting each fix:
  • Space put back into the helper: 5 checks fail
  • checked-state reporting removed: 2 fail
  • state-change event removed: 3 fail
  • interface replacement removed: 5 fail
  • auto-repeat guard removed: the held-key check fails
• ASR off (as check-windows builds): the MainWindow sources compile. Restoring the old comparison reproduces "'m_asrIndicator' was not declared in this scope".
• Demo session (DEMO-0001, AETHER_AUTOMATION_NO_TX=1, isolated settings): transmitting=false, the indicators carry their names, and a click on the band stack opens its panel.
• Full ctest: 673/673. The colour ratchet is flat, and the gates match the merge base apart from the two new files.
• Touchpoint: core/ThemeManager.h gains one includer, StatusIndicator.cpp, for the underline's colour token (maintainer-accepted).
• Not verified:
  • A real screen reader (Orca, NVDA, JAWS). In particular, whether each one re-queries after ObjectDestroyed/ObjectCreated.
  • check_a11y. It can't see this change, because the indicators are declared in the header and handled in another file, so its silence isn't evidence.

Checklist

• Signed commits
• No new settings keys or dependencies
• Colours through ThemeManager tokens (color.canon.cyan)
• No CHANGELOG entry

🤖 Generated with Claude Code

[aethersdr-agent]

check-windows Build: m_asrIndicator referenced outside its #ifdef

Good news first — this is a one-line config guard, not a problem with the design. build (Linux) and the four static/analysis jobs are green, and the break is confined to a single comparison.

Note on method: get_ci_run_log returned only step names for this run, no compiler output, so I read the diff against the Windows job's configure flags rather than quoting a log line. The chain below is from the tree and ci.yml, not from an error message I saw.

The defect

The new predicate tests the ASR indicator unconditionally — src/gui/MainWindow_Shortcuts.cpp:869:

return obj && (obj == m_asrIndicator || obj == m_cwxIndicator || obj == m_tnfIndicator

But that member only exists in an ASR build — src/gui/MainWindow.h:1738-1740:

#ifdef AETHER_ASR_ENABLED
    QLabel* m_asrIndicator{nullptr};  // status-bar ASR (Copy Assist) toggle
#endif

And check-windows is the one job that configures ASR off — .github/workflows/ci.yml ~line 698:

# ASR OFF for this PR sanity check: its job is Windows-only APP
# regressions (WASAPI, Q_OS_WIN), not ASR. ...
"-DENABLE_ASR=OFF",

So on that job AETHER_ASR_ENABLED is undefined, the member is not declared, and the reference is an undeclared-identifier error (MSVC C2065). Linux has ASR on, so the symbol is there and the same line compiles — which is why only the Windows lane is red. This is config scope, not an MSVC quirk: any platform configured -DENABLE_ASR=OFF would fail identically.

Worth saying that the rest of the ASR handling in this PR is already correct: activateStatusIndicator()'s ASR branch is inside the #ifdef (MainWindow_Shortcuts.cpp:877-884), and so is keyboardOperable(m_asrIndicator) in MainWindow.cpp. I checked the other nine indicators (m_cwxIndicator, m_tnfIndicator, m_fdxIndicator, m_bandStackIndicator, m_tgxlContainer, m_pgxlContainer, m_txIndicator, m_addPanLabel, m_dvkIndicator) — all declared unconditionally in MainWindow.h. isStatusIndicator() is the only leaking site.

Suggested fix

bool MainWindow::isStatusIndicator(const QObject* obj) const
{
    if (!obj) return false;
#ifdef AETHER_ASR_ENABLED
    if (obj == m_asrIndicator) return true;
#endif
    return obj == m_cwxIndicator || obj == m_tnfIndicator || obj == m_fdxIndicator
        || obj == m_bandStackIndicator || obj == m_tgxlContainer || obj == m_pgxlContainer
        || obj == m_txIndicator || obj == m_addPanLabel || obj == m_dvkIndicator;
}

That keeps the shared-action design exactly as written and mirrors the guard you already used in activateStatusIndicator().

Reproducing it locally

Your local build has ASR on, so it cannot show this — which is why a full green local ctest (673/673) was consistent with a red Windows lane. An ASR-off configure reproduces it on macOS or Linux, no Windows host needed:

cmake -B build-noasr -DENABLE_ASR=OFF
cmake --build build-noasr --target AetherSDR

Worth keeping that arm around whenever a change touches status-bar members, since AETHER_ASR_ENABLED is the only #ifdef in that member block.

Everything else

• build (Linux), Static checks, Sanitizer option configures, and both CodeQL Analyze jobs: green.
• check-macos was still in_progress when I pulled the check runs, so I can't report it either way yet. It builds with ASR on, so this particular line won't be its problem.
• No reviewer or Copilot comments on the PR to cross-reference.
• status_indicator_test isn't built by check-windows — that job deliberately links the app plus a handful of MSVC-specific tests rather than the all target — so the failure is in the AetherSDR target itself, not your new test.

Nice piece of work on the underlying change, by the way: routing the mouse press and the keyboard through one activateStatusIndicator() is the right shape, and the child-bar focus mark neatly sidesteps the whole-sheet setStyleSheet() problem that would have eaten a stylesheet rule. Thanks for taking on the interactive-QLabel cleanup — ten indicators is real work.

Reference: docs/a11y.md · src/gui/MainWindow_Shortcuts.cpp · .github/workflows/ci.yml

🤖 Generated with Claude Code

---

_{🤖 aethersdr-agent · cost: $6.2497 · model: claude-opus-5}

[aethersdr-agent]

Antares Detector — candidate vulnerable file(s)

• src/gui/SmartMtrConfig.cpp
• src/gui/SmartMtrWidget.cpp

The indicatorPosition implementation in src/gui/SmartMtrConfig.cpp calls meterConfig(in.kind).valueToPosition(...) and clamps the result, but the valueToPosition implementation is not shown here and may perform unsafe array indexing/scaling on untrusted input. This can lead to out-of-bounds access or unsafe scaling if valueToPosition uses direct indexing or assumes valid min/max ranges.

_{Localized by Cisco Foundation AI Antares-1B running locally in the AetherClaude sandbox, seeded by the Cartographer security map. Advisory only — please verify before acting.}

---

_{🤖 aethersdr-agent · cost: $6.8560 · model: claude-opus-5}

[ten9876]

Issue fit: partially fixes #6257; recommendation: Request changes. The ten indicators receive focus, key handling and a shared activation path, matching the issue and the maintainer rulings disclosed in the body. However, ASR-disabled builds fail, and starting with accessibility active leaves the original accessibility interfaces cached, so the screen-reader activation requirement is still broken.

Scope audit

File/group	Change	Claimed?	Verdict
src/gui/MainWindow.cpp	Attach helpers to ten indicators; add missing names	Yes	In scope
src/gui/MainWindow.h, MainWindow_Shortcuts.cpp	Share mouse/keyboard actions and recognize indicators	Yes	In scope; blocker 1
src/gui/StatusIndicator.{h,cpp}	Focus, key handling, Button/Press interface, token-based underline	Yes	In scope; blocker 2
CMakeLists.txt	Compile the helper into the GUI	Yes	Necessary wiring
tests/status_indicator_test.cpp, tests/tests.cmake	Register socket-free helper coverage	Yes	In scope; misses active-at-construction accessibility
docs/architecture/aetherd-touchpoints.md	ThemeManager includers 167 → 168	Explicitly disclosed	In scope

Everything in the diff is explained by the issue. One signed commit, with no unrelated commit history, new setting/dependency/default, or CHANGELOG entry. GitHub verifies the signature. The maintainer's explicit ten-indicator/helper/underline rulings address the UX/design choices.

Blockers

1. [P1] ASR-disabled configurations do not compile — src/gui/MainWindow_Shortcuts.cpp:869.

   isStatusIndicator() compares against m_asrIndicator unconditionally, but MainWindow.h:1738 declares that member only under AETHER_ASR_ENABLED. The Windows job configures ENABLE_ASR=OFF. I independently obtained its compiler output, rather than relying on the existing bot's inference:

   MainWindow_Shortcuts.cpp(869): error C2065: 'm_asrIndicator': undeclared identifier
   

   Failing required Windows job. This affects every platform building with ASR off. Keep the conditional member comparison under the same guard:

   bool MainWindow::isStatusIndicator(const QObject* obj) const
   {
       if (!obj) {
           return false;
       }
   #ifdef AETHER_ASR_ENABLED
       if (obj == m_asrIndicator) {
           return true;
       }
   #endif
       return obj == m_cwxIndicator || obj == m_tnfIndicator
           || obj == m_fdxIndicator || obj == m_bandStackIndicator || obj == m_tgxlContainer
           || obj == m_pgxlContainer || obj == m_txIndicator || obj == m_addPanLabel
           || obj == m_dvkIndicator;
   }

2. [P1] Active accessibility caches the original interface before attachment — src/gui/StatusIndicator.cpp:69; construction order at src/gui/MainWindow.cpp:5805, coverage at tests/status_indicator_test.cpp:97.

   The app sets accessible names before keyboardOperable() attaches the helper. With accessibility already active, Qt resolves and caches the original interface during these change notifications. Installing a factory and adding the helper property does not replace a cached interface. Subsequent queries return the original StaticText interface for a label, without a Press action; containers also retain their original role.

   Reproduced on the pinned Qt 6.12, using the PR's actual helper, without a custom accessibility handler:

   active=1
   name-before-attach role=41 expected=43
   cached label: before_role=41 after_role=41 expected_button=43 same_interface=1 press=0
   

   41 is StaticText and 43 is Button. The unmodified test passes 16/16. Moving its existing QAccessible::setActive(true) before widget construction produces 12/16, failing Button role, Press action availability/activation, and container Button role. No native screen-reader speech was measured: this is a deterministic reproduction at the Qt interface consumed by assistive technology.

   Qt's implementation explicitly resolves interfaces during active accessibility updates and consults the cache before factories: Qt accessibility implementation. Invalidate the previous interface after attaching the helper; include an active-before-construction regression. This replacement for the return at line 69 restored 16/16 in the adversarial variant:

       StatusIndicator* helper = new StatusIndicator(widget);
       if (QAccessibleInterface* iface = QAccessible::queryAccessibleInterface(widget)) {
           QAccessible::deleteAccessibleInterface(QAccessible::uniqueId(iface));
       }
       return helper;

   Also verify platform accessibility notifications when replacing an interface that an AT client has already observed.

Non-blocking nit

• src/gui/StatusIndicator.cpp:117: repeated KeyPress events activate repeatedly. One Space press followed by one isAutoRepeat() event emitted two activations. Consider consuming auto-repeat without activating for these toggle/cycle controls, and cover it with a socket-free test. Holding Space can otherwise repeatedly toggle a panel or cycle TUN/AMP state.

Verification and limits

The new test owns no sockets and contains no synthetic device peer. The original 16 checks passed; removing key activation made five checks fail (11/16), demonstrating meaningful keyboard coverage. Disabled activation, unrelated keys, inner-label roles and underline geometry/focus behavior survived the existing tests. Active-before-construction and cached-interface probes exposed blocker 2; the cache-invalidation variant restored all 16 checks.

Engine boundary remains 102 known findings/zero blockers, command plane remains 368 commands across 32 files, capability records/test registration/frozen CI gate/QSettings checks pass, and a11y lint reports zero findings on all five touched GUI files. Colour counts match base exactly: 582 unique colours, 2487 references, 893 stylesheet calls. No automated code-review skill was available; the existing bot's ASR diagnosis was independently verified. Its unrelated SmartMtr speculation supplies no evidence about this diff and is not adopted.

I independently configured and built AetherSDR and the registered status_indicator_test from the clean PR head e2c62cd98 in /tmp/pr6267-build; the registered test passed (1/1). A real two-indicator widget chain also passed Tab navigation. The earlier adversarial binaries compiled the actual head helper/test against unchanged base support libraries; the subsequent full head build independently passed the original test.

Two isolated offscreen head instances used fresh settings, explicit sockets and AETHER_AUTOMATION_NO_TX=1. Bridge ping reported sha=e2c62cd98, dirty=false; connect local serial DEMO-0001, connect wait, and get radio confirmed the demo, one pan/one slice and transmitting=false. An owned LD_PRELOAD Qt-entrypoint probe in the first instance queried all ten Button/Press interfaces and sent Space/accessible Press into the actual app:

REVIEW keyboard_space panel_before=0 panel_after=1
REVIEW keyboard_space panel_before=1 panel_after=0
REVIEW keyboard_space panel_before=0 panel_after=1
REVIEW accessible_press panel_before=1 panel_after=0

The second instance ran without instrumentation. Bridge clickAt on Band stack panel plus dumpTree returned panel visibility [true], [false], [true], confirming the mouse path still works. Generic invoke click does not support QLabel; coordinate clicks do. Both owned instances (pr6267-head-review, pr6267-mouse-review) were closed through their explicit sockets and exited successfully; the existing operator instance was untouched. I did not build/run a base app; the base's NoFocus/StaticText behavior was inspected, and deleting key activation produced the expected failing behavioral tests.

CI tested a pull_request merge created 2026-10-07 23:55:11 UTC after main's current tip (23:35:09 UTC), so it is not stale against current main. Linux/macOS/static checks pass; required Windows check fails. The author log records 673 selected tests with one skipped; I did not independently rerun the full suite or a native screen reader.

Recommendation: Request changes. Fix both blockers, add the active-at-construction regression and rerun the required Windows job. This review is submitted as COMMENT because the authenticated account (ten9876) is also the PR author, which GitHub does not permit to request changes on its own PR.

[ten9876]

All addressed in 55990b5bc.

Review blockers

1. ASR-off builds don't compile. Fixed with your guard, at MainWindow_Shortcuts.cpp:869: m_asrIndicator is compared only under AETHER_ASR_ENABLED. Proof from a local -DENABLE_ASR=OFF tree (the check-windows configuration):

• MainWindow.cpp.o and MainWindow_Shortcuts.cpp.o now compile.
• Restoring the old line reproduces GCC's form of the MSVC C2065: 'm_asrIndicator' was not declared in this scope.

2. A cached interface survives attach(). Fixed in StatusIndicator::attach(). When accessibility is active and the widget already has a cached interface that isn't a Button, the helper:

• deletes it, so the next query builds the Button with its Press action;
• sends ObjectCreated, so an assistive client that already saw the old object looks again. That covers your point about platform notifications.

status_indicator_test now builds a label and a container after accessibility is active, names them before attaching (as MainWindow does), and checks that:

• each comes back as a Button and keeps its name;
• Press is offered and activates it;
• each sends ObjectCreated once.

With the replacement removed, 5 checks fail (19/24).

Nit

Auto-repeat. Return/Enter/Space auto-repeat is consumed without acting, so holding a key no longer re-toggles a panel or cycles TUN/AMP. A held-Space event is consumed with no second activation. With the guard removed, that check fails.

Bot comments

• check-windows: this is the same root cause as blocker 1, fixed as described there.
• SmartMtr "candidate vulnerable files": not adopted. This PR doesn't touch SmartMtrConfig.cpp or SmartMtrWidget.cpp, and the comment gives no evidence connecting them to this diff.

Verification

• status_indicator_test: 24/24.
• Full ctest: 673/673.
• check_a11y: nothing on the touched files.
• Engine boundary, capability records, command plane, test registration, CI gate and QSettings checks pass, and the touchpoint manifest is current.
• The PR description now describes all three changes.

[aethersdr-agent]

Issue fit

Partially. #6257 asks for Qt::TabFocus, activation with Return or Space, and a Button role on the click-only status-bar indicators. Tab focus, Return/Enter, the Button role and the accessible Press action all land, and the StatusIndicator helper is a genuinely good shape — one action path shared by mouse and keyboard, a child focus bar that sidesteps the whole-sheet setStyleSheet() problem, and the DVK panel finally has a non-mouse entry point, which was the worst part of the issue. Space does not work in the app, for a reason the helper can't see from where it sits (Blocker 1), and the scope expansion past the five styled indicators rests on rulings I can't find (Blocker 2).

Scope

File / group	What it changes	Claimed by title or body?	Verdict
src/gui/StatusIndicator.{h,cpp}	New helper: focus policy, key activation, Button role + Press, focus underline	Yes	In scope
src/gui/MainWindow.cpp (buildUI)	keyboardOperable() lambda on ten indicators; five new accessible names	Yes	In scope
src/gui/MainWindow_Shortcuts.cpp	Press branches extracted to isStatusIndicator / activateStatusIndicator	Yes	In scope
src/gui/MainWindow.h	Two slot declarations	Yes	In scope
CMakeLists.txt	GUI_SOURCES += StatusIndicator.cpp	Implied	In scope — required, the file would otherwise be a dead addition
tests/status_indicator_test.cpp, tests/tests.cmake	New registered test, matches the dvk_panel_theme_test block above it verbatim	Yes	In scope
docs/architecture/aetherd-touchpoints.md	core/ThemeManager.h includers 167 → 168	Yes, disclosed explicitly	In scope

No CHANGELOG entry, no new settings keys, no new public/protocol surface, no deleted guards. The scope expansion from five indicators to ten is a scope question but it's disclosed in the body, so it's Blocker 2 rather than an undisclosed row here.

Blockers

1. src/gui/StatusIndicator.cpp:124-133 — Space never reaches the helper when a radio is connected; it keys the transmitter instead.

        if (key == Qt::Key_Return || key == Qt::Key_Enter || key == Qt::Key_Space) {

MainWindow is installed as an application-level event filter (src/gui/MainWindow.cpp:1547, qApp->installEventFilter(this)). Qt runs application filters before the receiving object's own filters (QCoreApplication::notify → sendThroughApplicationEventFilters → sendThroughObjectEventFilters), so MainWindow::eventFilter sees every KeyPress before StatusIndicator::eventFilter does. That filter calls handlePttHoldShortcut on every key press (src/gui/MainWindow_Shortcuts.cpp:735), and ptt_hold is bound to Space by default (src/gui/MainWindow_Shortcuts.cpp:1229, QKeySequence(Qt::Key_Space), keysTx=true).

With a focused indicator, pttHoldKeyStep(KeyPress, holdActive=false, shortcutsEnabled=true, textEntryCaptured=false, connected=true) returns KeyTx — a focused QLabel is not text entry — and the branch returns true. src/gui/PttHoldKeyStep.h says so in its own comment: "Consume the bound key so it cannot also activate a button."

So in the primary operating state (connected, shortcuts on), Tab to FDX, CWX, "Cancel transmit" or the AMP stack and press Space → MOX keys for as long as the key is held, and the indicator does not activate. Disconnected, or with shortcuts off, pttHoldKeyStep returns PassThrough and Space works — which is exactly the state the body's one instrumented run was in ("offscreen, isolated profile, no radio"). The body lists keyboard activation in the running app under "Not verified", so this is the gap that check would have closed.

tests/status_indicator_test.cpp:95 (report("Return, Enter and Space each activate it", dvkActivations == 3)) can't see it either: the test installs no application-level filter, so the assertion is true of the helper in isolation and false of the helper in the app. Space is the key assistive technology presses on something advertised as a Button, so a screen-reader user tabbing to the DVK indicator and pressing Space keys the radio rather than opening the panel.

This is also precisely what #6257's triage comment asked to be ruled on — "Return vs Space — needs a decision".

Smallest honest fix: drop Space from the helper and say so in the body. Return/Enter plus the accessible Press action still satisfy the issue, and #6257's ask for Space becomes a maintainer call about whether a focused indicator should steal Space from PTT:

        if (key == Qt::Key_Return || key == Qt::Key_Enter) {

Please don't route the helper through ShortcutManager to resolve this — that couples a generic widget helper to MainWindow. If the maintainer does want Space, it belongs in the app-level filter ahead of handlePttHoldShortcut, and that is a TX-behaviour change deserving its own ruling. Either way there is a deterministic, policy-compliant pin available: tests/window_shortcut_test.cpp:272 already drives ptt_hold through a filter, so "focused helper + connected + shortcuts on → Space does not activate, Return does" is testable at that seam without a fake radio.

2. src/gui/MainWindow.cpp:5743-6207 — the three "maintainer rulings" the scope rests on aren't in either thread.

The body states: "Maintainer rulings: all ten indicators; keep them as QLabels and add focus and keys, rather than converting them to buttons; a cyan underline as the focus mark." I read every comment on #6257 and on this PR. #6257 has one comment, from aethersdr-agent[bot], and it recommends the opposite on scope:

I'd hold this issue to the five indicators that genuinely share the greyIndLg / setIndicatorStyle path. … the TGXL/PGXL containers cycle an amplifier into OPERATE, so giving them a focusable Space target deserves its own look. m_txIndicator is … a different widget with different semantics; separate issue.

#6257 still carries the maintainer-review label. I'm not calling the claim false — the ruling may have arrived somewhere I can't see — but it's unverifiable from the record, and it reverses a documented recommendation. Two of the five added indicators are the ones that comment carved out: m_tgxlContainer (:6134) and m_pgxlContainer (:6172). Tab + a keystroke now cycles a tuner through BYPASS/STANDBY and puts an amplifier into OPERATE, which is the "own look" that was asked for. Routing this to Needs maintainer decision on scope: either link the ruling, or split TUN/AMP (and arguably TX) into a follow-up and land the eight uncontested ones.

Worth noting the keyboard reach for TUN/AMP intersects Blocker 1: with Space taken by PTT, those two cycle on Return/Enter only today.

Nits

• tests/status_indicator_test.cpp:110-113 — report("a disabled indicator does not activate", ...) calls dvkHelper->activate() directly rather than sending a key to the disabled widget, so it pins the isEnabled() guard inside activate() but not the end-to-end disabled path. Cheap to strengthen: press(dvk, Qt::Key_Return) while disabled, alongside the direct call.
• src/gui/MainWindow.cpp:10489 — m_dvkIndicator->setEnabled(dvkAvailable). Qt skips disabled widgets in the tab chain, so the accessibleDescription carrying the live unavailability reason (#6247, :10508) is unreachable to a keyboard-only screen-reader user, even though docs/a11y.md:194-213 makes that description the channel the reason must travel on. Tree-browsing AT still finds it, so this is not a regression this PR introduces — but "dimmed with a reason" and "focusable" are in tension and the PR is the first thing to make it visible. Out of scope to fix here; worth a follow-up note.
• The body cites check_a11y reporting nothing on the touched files as evidence. It can't report anything here: as #6257's own triage established, Check 1 builds its label set per-file from local declarations and looks within ±6 lines of the eventFilter token, and these indicators are header-declared and handled in a different translation unit. A clean run is vacuous for this change, not confirmation.
• src/gui/StatusIndicator.h:12-15 — the class comment promises "Return/Enter/Space activate it". Needs the same correction as the body if Blocker 1 lands as suggested.

What I tried to break

• The refactor dropping a guard. Walked all ten extracted branches against their - lines: every if (!x->isEnabled()) return true; became return inside activateStatusIndicator with the filter still returning true, so consumption is unchanged; the TX left-button-only gate survived at the filter (MainWindow_Shortcuts.cpp:856-859) and is behaviourally identical to the old inner check. FDX's command-then-apply-on-reply shape moved verbatim. No guard lost.
• The ASR-off lane. isStatusIndicator and activateStatusIndicator both guard m_asrIndicator under AETHER_ASR_ENABLED, as does keyboardOperable(m_asrIndicator). The member set in isStatusIndicator matches the ten old press branches exactly — nothing added, nothing dropped. check-windows (the only -DENABLE_ASR=OFF lane) is green on 55990b5, as are build, check-macos, Static checks, Sanitizer configures and both CodeQL jobs.
• Stylesheet cascade eating the focus bar. The indicators repolish with whole-sheet setStyleSheet(), and Qt sheets cascade to children — but every sheet in that path is QLabel {-selected (MainWindow.cpp:5657-5660, 10396-10398) and the focus bar is a bare QWidget, so none of them match it. The TUN/AMP containers set no sheet at all. The child-bar approach holds.
• Lifetime and dangling state. StatusIndicator is QObject(widget)-parented, so the aetherStatusIndicator property can never outlive its target; the MainWindow connect takes this as context and the sender dies with the indicator, so the lambda can't fire into a dead widget; doAction null-checks of(widget()). attach() is idempotent via the early of() return, and installFactory runs once behind a function-local static.
• Inner labels of a container turning into buttons. The factory keys on the helper property, which only the container carries, so TUN/OPERATE stay StaticText — the test pins this at :131-133 and the mechanism agrees.
• Theme token and test registration. color.canon.cyan resolves in both themes (#005f85 light, #5de3ff dark) — I walked the JSON rather than grepping, since those tokens are nested. The tests.cmake block mirrors the dvk_panel_theme_test registration above it (same link set, THEME_TEST_RESOURCES, offscreen, TIMEOUT 60), and StatusIndicator.cpp is referenced from both GUI_SOURCES and the test target, so neither is a dead addition.
• Socket tests: none added, modified or removed by this PR.
• Could not check: no build and no GUI here, so the focus bar's painting and placement inside the TUN/AMP containers (its child is created before their QVBoxLayout and is never laid out), real AT behaviour, and whether NVDA/Orca/JAWS actually re-query on the ObjectCreated the interface replacement sends. The body already flags the last of those honestly. Every finding above is reasoned from the code in the head checkout, not reproduced at runtime — including Blocker 1, which rests on Qt's documented filter ordering plus three source sites rather than an observed keystroke.

Recommendation

Request changes, on Blocker 1 alone — the advertised key does the wrong thing in the state that matters, and what it does instead is key the transmitter. The fix is one line plus a body correction, and the mechanism is a seam the helper genuinely couldn't see from inside itself; a pin at window_shortcut_test.cpp would keep it from coming back. Blocker 2 is for the maintainer, not for you: link the ruling and it evaporates, or split TUN/AMP out and the remaining eight are ready.

Everything else here is solid work. One action path for mouse and keyboard is the right shape, the cached-interface replacement in attach() is a subtlety most implementations miss, and the invert-each-fix test discipline is exactly what Principle VIII is asking for. Ten indicators is real work — thank you for taking the interactive-QLabel cleanup on rather than doing just the DVK one.

---

_{🤖 aethersdr-agent · cost: $5.6748 · model: claude-opus-5}

[ten9876]

All addressed in be90925ef.

aethersdr-agent review

Blocker 1: Space keys TX. Confirmed and fixed. MainWindow's app-level filter runs first and turns Space into PTT (Hold) when connected with shortcuts on, so a focused indicator never saw it. Per the maintainer's ruling, the helper now activates on Return/Enter only and leaves Space alone, so Space means PTT everywhere, as for every other button.

• status_indicator_test now runs the real pttHoldKeyStep() as an app-level filter (connected, shortcuts on). Behind it, Space on a focused indicator is PTT and does not activate it, while Return activates it and keys nothing.
• With Space put back into the helper, 5 checks fail.
• The class comment and the PR description are corrected.

Blocker 2: rulings not on record. The rulings were given to the agent in session. They are now recorded on #6257, and the maintainer confirmed keeping all ten, TUN/AMP/TX included. Those three are keyboard-operable on Return/Enter and the Press action.

Nits:

• Disabled-path test: it now sends a real Return to the disabled indicator, as well as calling activate().
• Disabled indicators unreachable by Tab: maintainer ruling, left as Qt does. The reason stays reachable by screen-reader object navigation.
• check_a11y claim: removed from the description. You're right that it can't see this change.
• Class comment: corrected for Space.

Automated code-review pass

• Space keys TX: same as Blocker 1 above.
• On/off state not exposed: maintainer ruled to fold it in. TNF, FDX, CWX, ASR, DVK and the band stack are now checkable and report checked state at every restyle site, with one StateChanged per real change. TUN and AMP lead their description with their state word. Removing the state reporting fails 2 checks; removing the event fails 3.
• No ObjectDestroyed on interface replacement: fixed. The old object is retired with ObjectDestroyed, then ObjectCreated announces the Button. The test checks the order.
• Factory runs a property lookup at every class level: fixed. It now acts only at the object's most-derived class.
• Two registries for mouse and keyboard: maintainer ruling, keep the single shared dispatcher, so mouse-button semantics are unchanged.
• Dead isEnabled() guards: not changed. They were moved verbatim and are harmless, and I can't demonstrate they're unreachable.

Verification

• status_indicator_test 33/33; full ctest 673/673.
• ASR-off compiles.
• Demo bridge session (DEMO-0001, NO_TX): transmitting=false, names present, and a band-stack click opens its panel.
• Gates match the merge base apart from the two new files, and the colour ratchet is flat.