[GH-ISSUE #223] fix: ask_user panel commits the answer on radio selection, making later options unreachable by keyboard #136

New issue

Open

opened 2026-10-18 14:03:17 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

2026-10-18 14:03:17 +00:00

Owner

Originally created by @ThalynLabs on GitHub (Aug 15, 2026).
Original GitHub issue: https://github.com/open-webui/computer/issues/223

What happens

In the plan-mode ask_user question panel, selecting a radio option immediately submits the answer. The panel's own submit control is not what commits it — activating an option is.

This makes the options unreviewable for anyone using a keyboard or a screen reader.

Radio groups implement selection follows focus — per the ARIA Authoring Practices radio group pattern (and native HTML radio behaviour), arrow keys move focus and check the option landed on. Combined with submit-on-select, that means:

Pressing the first arrow key submits the answer.
Options after the first are effectively unreachable without committing to them.
The option description text — the most useful part of the panel — is never heard, because the turn has already resumed.

I use VoiceOver on macOS. In practice I cannot browse the choices at all; I can only take whichever option focus lands on first.

Why this is a conformance problem, not just friction

WCAG 2.2 SC 3.2.2 On Input (Level A) — "Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behavior before using the component." Checking a radio is a setting change; submitting the answer and resuming the agent turn is a change of context. No advisory precedes it.

It also undermines SC 2.1.1 Keyboard (Level A) in effect: the functionality of choosing among options 2..n is not operable via keyboard without irreversibly selecting the options passed through on the way.

Worth noting the radio behaviour on its own is correct and specified — the defect is the coupling of selection to submission.

Suggested fix

Either would resolve it:

Decouple selection from submission. Radios set the pending answer; the existing submit control commits it. Smallest change, keeps native radio semantics and the current markup.
Use the listbox pattern (role="listbox" / role="option", roving tabindex or aria-activedescendant), where selection does not follow focus and Enter/Space commits. The APG recommends this specifically when a user needs to review options before choosing.

Option 1 is likely a few lines and preserves everything else about the component.

Environment

cptr 0.9.21
macOS, VoiceOver
Panel markup renders as <label><input class="sr-only" type="radio"> …</label> — the visually-hidden-radio pattern itself is fine; the change handler is where the submit happens.

Originally created by @ThalynLabs on GitHub (Aug 15, 2026). Original GitHub issue: https://github.com/open-webui/computer/issues/223 ### What happens In the plan-mode `ask_user` question panel, **selecting a radio option immediately submits the answer**. The panel's own submit control is not what commits it — activating an option is. This makes the options unreviewable for anyone using a keyboard or a screen reader. Radio groups implement *selection follows focus* — per the ARIA Authoring Practices radio group pattern (and native HTML radio behaviour), arrow keys move focus **and check** the option landed on. Combined with submit-on-select, that means: - Pressing the first arrow key submits the answer. - Options after the first are effectively unreachable without committing to them. - The option `description` text — the most useful part of the panel — is never heard, because the turn has already resumed. I use VoiceOver on macOS. In practice I cannot browse the choices at all; I can only take whichever option focus lands on first. ### Why this is a conformance problem, not just friction **WCAG 2.2 SC 3.2.2 On Input (Level A)** — "Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behavior before using the component." Checking a radio is a setting change; submitting the answer and resuming the agent turn is a change of context. No advisory precedes it. It also undermines **SC 2.1.1 Keyboard (Level A)** in effect: the functionality of choosing among options 2..n is not operable via keyboard without irreversibly selecting the options passed through on the way. Worth noting the radio behaviour on its own is correct and specified — the defect is the coupling of selection to submission. ### Suggested fix Either would resolve it: 1. **Decouple selection from submission.** Radios set the pending answer; the existing submit control commits it. Smallest change, keeps native radio semantics and the current markup. 2. **Use the listbox pattern** (`role="listbox"` / `role="option"`, roving tabindex or `aria-activedescendant`), where selection does not follow focus and <kbd>Enter</kbd>/<kbd>Space</kbd> commits. The APG recommends this specifically when a user needs to review options before choosing. Option 1 is likely a few lines and preserves everything else about the component. ### Environment - cptr 0.9.21 - macOS, VoiceOver - Panel markup renders as `<label><input class="sr-only" type="radio"> …</label>` — the visually-hidden-radio pattern itself is fine; the change handler is where the submit happens.

bsakaguchi commented

2026-10-18 14:03:18 +00:00

Author

Owner

@ThalynLabs commented on GitHub (Aug 15, 2026):

Correcting and sharpening the above with an actual keyboard walkthrough, rather than the inference I opened with. The failure is more severe than I described.

Observed, VoiceOver on macOS:

The radio group cannot be reached by forward Tab in normal reading order — reaching it requires Shift+Tab backwards from below, which lands on the last control in the group ("Other", announced as "4 of 4").
From the first radio, pressing ↓ does not move to the second radio. Focus jumps out of the group to the free-text "Other" input — and the answer is submitted in the process.

So the consequence is not merely that options can't be reviewed before choosing. Options 2..n cannot be selected by keyboard at all. The only reachable choices are the first radio and the free-text box, and the single arrow keypress that would take you anywhere else commits the answer.

This makes it a direct SC 2.1.1 Keyboard (Level A) failure, not only the 3.2.2 On Input failure in the original report: the functionality of choosing option 2 or 3 is not operable through a keyboard interface.

Two things appear to be wrong together:

Arrow keys are not scoped to the radio group. Per the ARIA radio group pattern, ↓/→ should move to the next radio within the group and wrap at the end — never move focus out of it. The free-text input should be a separate tab stop, not an arrow-key destination.
Selection is wired to submission, so any focus/selection movement commits.

Fixing the second alone would restore reviewability; fixing both is needed to make options 2..n selectable at all.

Happy to test a fix against VoiceOver if that's useful.

@ThalynLabs commented on GitHub (Aug 15, 2026): Correcting and sharpening the above with an actual keyboard walkthrough, rather than the inference I opened with. The failure is more severe than I described. **Observed, VoiceOver on macOS:** 1. The radio group cannot be reached by forward <kbd>Tab</kbd> in normal reading order — reaching it requires <kbd>Shift</kbd>+<kbd>Tab</kbd> backwards from below, which lands on the **last** control in the group ("Other", announced as "4 of 4"). 2. From the **first** radio, pressing <kbd>↓</kbd> does **not** move to the second radio. Focus jumps out of the group to the free-text "Other" input — **and the answer is submitted in the process.** So the consequence is not merely that options can't be reviewed before choosing. **Options 2..n cannot be selected by keyboard at all.** The only reachable choices are the first radio and the free-text box, and the single arrow keypress that would take you anywhere else commits the answer. **This makes it a direct SC 2.1.1 Keyboard (Level A) failure**, not only the 3.2.2 On Input failure in the original report: the functionality of choosing option 2 or 3 is not operable through a keyboard interface. Two things appear to be wrong together: - **Arrow keys are not scoped to the radio group.** Per the ARIA radio group pattern, <kbd>↓</kbd>/<kbd>→</kbd> should move to the next radio *within* the group and wrap at the end — never move focus out of it. The free-text input should be a separate tab stop, not an arrow-key destination. - **Selection is wired to submission**, so any focus/selection movement commits. Fixing the second alone would restore reviewability; fixing both is needed to make options 2..n selectable at all. Happy to test a fix against VoiceOver if that's useful.

bsakaguchi referenced this issue

2026-10-18 14:04:31 +00:00

[PR #136] [MERGED] refac #300