Step 2 / 3
``` The order and type of the buttons are part of the specification. The "Next" button is the form's **first submit button**; a user who presses Enter while in a text field runs this button. The "Back" button carries `type="button"`; if it did not, implicit submission would take the form backward, and the user would lose a step. ## A Step Change Is Not a Page Change In a transition made by refreshing the page, focus returns to the start of the document, and the user enters the new document from the top. In a transition made without refreshing the page, nothing happens on its own: the content on screen changes, focus stays on the old button, and for a user who cannot see the screen, it looks as if nothing happened. The specification requires three things: focus moves to the new step's heading, the transition is announced with a polite live region, and the step indicator states which step it is in text. The heading carrying `tabindex="-1"` is so it can take focus without entering the tab order. The script below runs the same scenario under two layouts and checks four rules. ```js // form.mjs — auditing focus management, announcements, and value preservation in a multi-step form const STEPS = [ { name: "Record confirmation", heading: "step-1", fields: [ { id: "record", label: "Record number", required: true, rule: (v) => /^K-\d{3}$/.test(v), message: "Record number must be in the K-000 format." }, ] }, { name: "Member information", heading: "step-2", fields: [ { id: "member-no", label: "Membership number", required: true, rule: (v) => /^\d{8}$/.test(v), message: "Membership number must be 8 digits." }, { id: "email", label: "Notification address", required: false, rule: (v) => v === "" || v.includes("@"), message: "Enter a valid email address." }, ] }, { name: "Duration and confirmation", heading: "step-3", fields: [ { id: "duration", label: "Borrow duration", required: true, rule: (v) => ["14", "21", "28"].includes(v), message: "Select a borrow duration." }, ] }, ]; const initial = () => ({ step: 0, values: {}, errors: [], focus: "input#record", announcement: "", done: false, }); function validate(step, values) { const h = []; for (const a of STEPS[step].fields) { const v = values[a.id] ?? ""; if (a.required && v === "") h.push([a.id, a.label, "This field is required."]); else if (v !== "" && !a.rule(v)) h.push([a.id, a.label, a.message]); } return h; } // layout: movesFocus, announcesTransition, preservesValues function machine(layout) { const focusTo = (target, previous) => (layout.movesFocus ? target : previous); const announce = (m) => (layout.announcesTransition ? m : ""); return (d, e) => { if (e.kind === "input") return { ...d, values: { ...d.values, [e.id]: e.value } }; if (e.kind === "back") { if (d.step === 0) return d; const y = d.step - 1; return { ...d, step: y, errors: [], values: layout.preservesValues ? d.values : {}, focus: focusTo("h2#" + STEPS[y].heading, d.focus), announcement: announce(`Step ${y + 1} / ${STEPS.length}: ${STEPS[y].name}`) }; } if (e.kind === "next" || e.kind === "submit") { const errors = validate(d.step, d.values); if (errors.length > 0) { return { ...d, errors, focus: focusTo("div#error-summary", d.focus), announcement: announce(`${errors.length} field(s) need correction`) }; } if (e.kind === "submit" && d.step === STEPS.length - 1) { return { ...d, errors: [], done: true, focus: focusTo("h2#result", d.focus), announcement: announce("Borrow request recorded") }; } const y = Math.min(d.step + 1, STEPS.length - 1); return { ...d, step: y, errors: [], focus: focusTo("h2#" + STEPS[y].heading, d.focus), announcement: announce(`Step ${y + 1} / ${STEPS.length}: ${STEPS[y].name}`) }; } return d; }; } const SCENARIO = [ { kind: "input", id: "record", value: "K-118" }, { kind: "next" }, { kind: "input", id: "member-no", value: "1234" }, { kind: "next" }, { kind: "input", id: "member-no", value: "10045512" }, { kind: "next" }, { kind: "back" }, { kind: "next" }, { kind: "input", id: "duration", value: "21" }, { kind: "submit" }, ]; const FOCUSABLE = new Set([ "input#record", "div#error-summary", "h2#step-1", "h2#step-2", "h2#step-3", "h2#result", ]); function run(heading, layout, logTrace) { const next = machine(layout); let d = initial(); const trace = []; console.log(heading); if (logTrace) console.log(" action".padEnd(24) + "step".padEnd(31) + "focus".padEnd(20) + "announcement"); for (const e of SCENARIO) { const previous = d; d = next(d, e); trace.push({ e, previous, d }); if (!logTrace) continue; const label = e.kind === "input" ? `input ${e.id}` : e.kind; const stepName = d.done ? "result" : `${d.step + 1}/${STEPS.length} ${STEPS[d.step].name}`; console.log(" " + label.padEnd(22) + stepName.padEnd(31) + d.focus.padEnd(20) + (d.announcement || "-")); } const findings = []; for (const { e, previous, d: s } of trace) { if (e.kind === "input") continue; if (s.focus === previous.focus && s.step !== previous.step) findings.push(`${e.kind}: step changed, focus did not move`); if (s.errors.length > 0 && s.focus !== "div#error-summary") findings.push(`${e.kind}: error present, focus did not move to the summary`); if (!FOCUSABLE.has(s.focus)) findings.push(`${e.kind}: focus target is not focusable (${s.focus})`); if (s.announcement === "") findings.push(`${e.kind}: transition was not announced`); for (const k of Object.keys(previous.values)) { if (previous.values[k] !== s.values[k]) findings.push(`${e.kind}: value of the ${k} field was lost`); } } console.log(` findings: ${findings.length}`); for (const b of findings) console.log(" " + b); return trace; } run("flawed layout (focus does not move, transitions are not announced, values are cleared going back):", { movesFocus: false, announcesTransition: false, preservesValues: false }, false); console.log(""); const trace = run("fixed layout:", { movesFocus: true, announcesTransition: true, preservesValues: true }, true); const failed = trace.find(({ d }) => d.errors.length > 0).d; console.log("\nsummary links in the failed transition:"); for (const [id, label, message] of failed.errors) { console.log(` ${label}: ${message}`); } ``` ``` flawed layout (focus does not move, transitions are not announced, values are cleared going back): findings: 14 next: step changed, focus did not move next: transition was not announced next: error present, focus did not move to the summary next: transition was not announced next: step changed, focus did not move next: transition was not announced back: step changed, focus did not move back: transition was not announced back: value of the record field was lost back: value of the member-no field was lost next: error present, focus did not move to the summary next: transition was not announced submit: error present, focus did not move to the summary submit: transition was not announced fixed layout: action step focus announcement input record 1/3 Record confirmation input#record - next 2/3 Member information h2#step-2 Step 2 / 3: Member information input member-no 2/3 Member information h2#step-2 Step 2 / 3: Member information next 2/3 Member information div#error-summary 1 field(s) need correction input member-no 2/3 Member information div#error-summary 1 field(s) need correction next 3/3 Duration and confirmation h2#step-3 Step 3 / 3: Duration and confirmation back 2/3 Member information h2#step-2 Step 2 / 3: Member information next 3/3 Duration and confirmation h2#step-3 Step 3 / 3: Duration and confirmation input duration 3/3 Duration and confirmation h2#step-3 Step 3 / 3: Duration and confirmation submit result h2#result Borrow request recorded findings: 0 summary links in the failed transition: Membership number: Membership number must be 8 digits. ``` The flawed layout produces fourteen findings, and two of them are cascading defects: because values are cleared going back, the next two transitions also fail to pass validation. The only thing visible on screen is "the form going blank when you go back"; the remaining twelve findings never appear on screen. Two rows in the fixed run's trace need attention. In the fourth row, validation fails and focus goes to the error summary; the step number does not change. In the seventh row, going back is also a step change and requires the **same** focus and announcement handling as going forward; leaving the backward direction silent is a commonly skipped case. ## Keyboard Contract | Key | Behavior | |---|---| | `Tab` / `Shift+Tab` | Moves between fields in source order. | | `Enter` (single-line field) | Runs the form's first submit button. | | `Enter` (multi-line field) | Inserts a line break; does not submit the form. | | `Enter` (on a button) | Runs the focused button. | The contract's constraint is **which button** implicit submission runs. If the form's first submit button is "Back," a user who presses Enter in a field falls back a step. Every button that does not carry submission behavior is written with `type="button"`. ## Saving and Undo A borrow request produces a record; it is a binding operation on the user's own data. The 3.3.4 Error Prevention (Legal, Financial, Data) criterion requires **at least one** of three routes for this kind of submission: submission has to be reversible, entered data has to be checkable and correctable, or it has to be confirmed before submission. In the three-step form, the second route is established on its own: the last step shows all entered values as a summary and carries a link back to the relevant step next to each row. It is not enough for the summary to be plain text; the user has to be able to reach the field they want to correct with an action. Two additional rules are written into the specification. Leaving the page while unsaved changes exist is met with a warning; when the warning is a modal dialog, it requires focus management, and this is the next topic's responsibility. If there is a session timeout, 2.2.1 Timing Adjustable comes into play: the user has to be able to extend the time, or the data has to be preserved. A twenty-minute session silently wiping a long form removes this criterion. ## Measurable Constraints **3.3.2 Labels or Instructions** requires a label or instruction on every field; **3.3.1 Error Identification** requires the erroneous field to be identified in text; **3.3.3 Error Suggestion** requires a correction suggestion to be given when known. The "Membership number must be 8 digits" message in the check is the counterpart of this third criterion: it does not stop at reporting the error, it states the correct format. **1.3.5 Identify Input Purpose** requires the purpose to be declared programmatically on fields that collect the user's own information; the name and notification address fields in the borrowing form fall within this scope. **2.4.6 Headings and Labels** requires step headings to actually describe the content: "Step 2" is not a heading, "Member information" is the heading, and the step number is given in separate text. ## Common Mistake **The step indicator being only visual.** A filling bar or three dots that change color say nothing to a user who cannot see the screen. Catching it means checking whether the indicator's text equivalent is present in the tree. **Leaving the error summary where it was built.** When the summary is built but focus is not moved, the user cannot learn that submission failed. Catching it is the check's second rule: whether focus moves to the summary when an error exists is tested. **Leaving the backward direction silent.** The focus and announcement handling established for going forward is also required going back. Catching it means running both directions through the same rule set. **Building a single-field group.** Wrapping one field in a `fieldset` announces the field's name twice, together with the group name. Catching it means counting the number of fields inside the group. ## Summary - A form is split by independent decision sets, not by field count; short forms stay in a single view. - The criterion for grouping is that fields answer a shared question; single-field groups are not built. - A step change requires three operations: moving focus to the new step's heading, announcing the transition with polite priority, and giving the step indicator in text. Going back is also a step change. - The form's first submit button runs on implicit submission; buttons that do not carry submission behavior are written with `type="button"`. - 3.3.4 requires at least one of the routes of undo, correction, or confirmation for binding submissions; the correctable summary on the last step establishes the second route. - Most of the findings the check produces are not visible on screen; focus and announcement defects surface only through rule testing. ## Next Step Every component in this topic ran an action: running a search, applying a filter, submitting a form. The record titles in the results table, by contrast, do a different job — they take the user to another resource. The two can be made to look alike on screen, but their keyboard contracts, their roles in the tree, and what the user expects from them differ. The next lesson ties this distinction to a rule and shows which concrete breakages the confusion produces.