User Story
As a keyboard user, I want forms to clearly identify optional fields and follow a predictable focus order.
Context & Motivation
Optional inputs are not consistently marked across the app's forms.
Acceptance Criteria
Technical Notes
Confirmed: the shared Field component (Field.tsx) only has built-in support for marking a field required (renders an asterisk) — there is no equivalent built-in "optional" indicator. Every "(optional)" hint found (WizardDetailsStep.tsx, AddCardForm.tsx, NewStarterTaskModal.tsx, AddCustomStepModal.tsx) is ad-hoc text baked into that form's own label string, each phrased slightly differently, and some fields likely carry no marking at all.
Note: the modal focus behavior this issue originally raised (autofocus on open, focus restore on close, tab trapping) is already implemented correctly in both shared dialog primitives, Modal.tsx and SidePanel.tsx — that part of the original report does not hold and has been dropped.
Unconfirmed Observation
During the UX test, tab order specifically in the "Add token" step of the project-creation wizard was reported as unclear. A code review of TokenAddForm.tsx found plain labeled inputs with normal DOM tab order and no custom widget that would obviously break keyboard use, so this could not be reproduced from the code alone. Whoever picks this up should re-test the exact "Add token" flow and wizard step used during the UX test (tab from field to field with nothing but the keyboard) before deciding whether this is still open, since the cause may be state- or timing-dependent and not visible from a static code read.
User Story
As a keyboard user, I want forms to clearly identify optional fields and follow a predictable focus order.
Context & Motivation
Optional inputs are not consistently marked across the app's forms.
Acceptance Criteria
Technical Notes
Confirmed: the shared
Fieldcomponent (Field.tsx) only has built-in support for marking a fieldrequired(renders an asterisk) — there is no equivalent built-in "optional" indicator. Every "(optional)" hint found (WizardDetailsStep.tsx,AddCardForm.tsx,NewStarterTaskModal.tsx,AddCustomStepModal.tsx) is ad-hoc text baked into that form's own label string, each phrased slightly differently, and some fields likely carry no marking at all.Note: the modal focus behavior this issue originally raised (autofocus on open, focus restore on close, tab trapping) is already implemented correctly in both shared dialog primitives,
Modal.tsxandSidePanel.tsx— that part of the original report does not hold and has been dropped.Unconfirmed Observation
During the UX test, tab order specifically in the "Add token" step of the project-creation wizard was reported as unclear. A code review of
TokenAddForm.tsxfound plain labeled inputs with normal DOM tab order and no custom widget that would obviously break keyboard use, so this could not be reproduced from the code alone. Whoever picks this up should re-test the exact "Add token" flow and wizard step used during the UX test (tab from field to field with nothing but the keyboard) before deciding whether this is still open, since the cause may be state- or timing-dependent and not visible from a static code read.