Hi @NF0T — thanks for this. The failing check is Qt Accessibility Static Analysis, but it's a CI infrastructure bug in .github/workflows/a11y-check.yml, not your code. Your #ifdef HAVE_HIDAPI guards in src/gui/MainWindow.cpp look fine and have nothing to do with accessibility.

What's actually failing

The workflow's "Run accessibility check" step fails on PRs that touch src/gui/ and produce zero findings. The culprit is this line in .github/workflows/a11y-check.yml:43:

COUNT=$(grep -c "^::warning" /tmp/a11y_output.txt || echo "0")

When grep -c finds zero matches, it prints 0 to stdout and exits with status 1. The || echo "0" then runs as well, so $COUNT ends up being a two-line string: "0\n0". The next line then writes:

findings=0
0

…to $GITHUB_OUTPUT, which is malformed (the lone 0 isn't key=value) and the runner errors out the step.

I reproduced this locally against your branch's MainWindow.cpp:

$ COUNT=$(grep -c "^::warning" /tmp/a11y_output.txt || echo "0")
$ echo "COUNT=[$COUNT]"
COUNT=[0
0]

The script itself (tools/check_a11y.py) found 0 findings on your file — the failure is purely a shell-quoting bug in the workflow wrapper.

Why your PR is the trigger

The a11y workflow was added in #3289 and is fairly new. Most PRs don't touch src/gui/ so the workflow skips entirely. PRs that do touch src/gui/ and produce ≥1 warning go down a different branch and avoid this code path. Yours is the unfortunate combination: touches src/gui/, produces 0 findings, hits the bug.

What to do

Nothing on your end. Per the workflow's own comments and the check_a11y.py docstring, this check is "warnings only — the build is not blocked" — it's not a merge gate. A maintainer can either:

1. Fix the workflow (e.g. COUNT=$(grep -c "^::warning" /tmp/a11y_output.txt) || COUNT=0), or
2. Merge once the remaining checks (build, check-macos, check-windows, analyze) pass — those are still in progress as of this comment.

The actual change in this PR (gating triggerTMate2Overlay calls on HAVE_HIDAPI) is exactly the kind of small, surgical fix the project benefits from. Thanks for chasing it.

_{🤖 aethersdr-agent · cost: $15.9898 · model: claude-opus-4-7}

Thanks for catching and fixing this so fast, @NF0T — this one's on me. I added those five triggerTMate2Overlay(...) calls into applyFlexControlWheelAction in #3401 without checking that the function lives outside the HAVE_HIDAPI guard while the overlay enum + helper are HIDAPI-only. CI builds with hidapi, so the no-HIDAPI MinGW path that actually breaks never got exercised on the PR — a gap I should have reasoned about rather than relied on green checks for.

Your guard placement is exactly right and matches the #3344 UlanziDial pattern; runtime behaviour on HIDAPI builds is unchanged. Reviewed the diff — LGTM. Sorry for the cleanup, and thanks again.

73, Jan (svabi79)

Rebased onto current main as `f232c3cb` to pick up #3442's a11y workflow fix. Your code didn't trigger any a11y findings — same workflow-yaml bug that hit your #3439: the pre-#3442 step crashed writing the zero-findings result to `$GITHUB_OUTPUT`, even though the lint itself completed cleanly. Timing: CI ran 2026-06-06 19:31 UTC, #3442 merged 21:44 UTC.

No content changes to your fix — the `HAVE_HIDAPI` guards around the `TMate2Overlay` calls in `applyFlexControlWheelAction` are exactly as you wrote them. CI will re-run against `f232c3cb` and the a11y check will pass cleanly this time.

Principle XI.