Plan accessible forms, keyboard navigation, and system states

Accessibility belongs in the plan

Accessibility defects often begin before markup exists. The design assumes a mouse, leaves error timing undefined, or draws only the successful state. Implementation then fills those gaps with defaults nobody reviewed.

Plan three connected contracts for every important workflow: how a form communicates, how a keyboard reaches it, and how the interface behaves outside the ideal state.

Define form behavior

Every field needs a persistent label, an appropriate input type, and a clear relationship to help or error text. Placeholder text can demonstrate format, but it cannot replace the label once the person starts typing.

Choose validation timing intentionally. Validate format after a field has been completed or left, and avoid displaying an error while the person is still entering a valid value. On submission, focus an error summary or the first invalid field and preserve everything already entered.

Write error messages with three parts: what needs attention, why the value was rejected when that is useful, and what action will fix it. “Invalid input” satisfies none of them.

For long forms, group related controls with headings or fieldset and legend. Prefer one clear reading column unless fields form an obvious pair. Warn about unsaved changes only when data would actually be lost.

Draw the keyboard path

The DOM order should match the visual and task order. A person using Tab should move through interactive controls predictably, without visiting decorative elements or jumping between columns unexpectedly.

Use established keyboard behavior:

• Tab moves between control groups.
• Arrow keys move within radio groups, menus, tabs, and composite widgets.
• Enter activates the primary action where expected.
• Space toggles buttons, checkboxes, and switches.
• Escape closes a temporary layer and returns focus to its trigger.

Custom application shortcuts should supplement these conventions rather than replace them. Avoid browser and assistive-technology conflicts, support both Control and Command where appropriate, and never make a shortcut the only way to perform an action.

Nodlume's workspace includes a shortcut definer for recording application actions and bindings. Open a project workspace to define them beside the routes and features they serve.

Design five system states

For each data-dependent surface, plan more than the ideal result:

1. Ideal — complete data and all normal actions.
2. Empty — no records yet, with an explanation and useful next action.
3. Loading — progress that matches the expected duration and content shape.
4. Error — a specific failure with recovery or escalation.
5. Partial — some data or capabilities are unavailable, but the useful remainder stays visible.

Add offline, stale, and queued variants where the product can lose connectivity. Do not clear an offline warning merely because the browser reports a connection; verify that the next request succeeds.

Routine success usually needs quiet inline confirmation or an undoable toast. Reserve dedicated confirmation pages for consequential transactions. A modal saying “Success” after every save adds work without adding information.

Convert decisions into tests

Accessibility becomes durable when the plan states what must be proven. Useful acceptance cases include:

• Every field has a programmatically associated label.
• Submitting invalid data preserves values and moves focus to the error.
• The workflow completes without a pointing device.
• Opening and closing a dialog restores focus to its trigger.
• Loading is announced without repeatedly interrupting a screen reader.
• Empty and error states identify a next action.
• Reduced-motion preferences remove nonessential transitions.
• A shortcut conflict is rejected rather than silently replacing another action.

Attach each case to the page, component, store, or endpoint responsible for the behavior. Nodlume keeps those cases beside the planned surface and exports them as pending tests, turning accessibility from a late review into an implementation contract.