Help someone correct a form without losing valid answers

A quantity error should leave someone with one answer to correct. If the form also erases a valid project note, the person has to reconstruct work they already did. Define what stays, where the error appears, and how to reach the field before asking for a change.

This is an optional Part 4 guide in Test the app you built. Use the local teaching sample and the filled example and blank acceptance card to prepare one correction request for an existing app. The useful output is a record of exact values, messages and focus targets, with actual observations kept separate from expectations.

The example is a fictional workshop materials inquiry. It checks answers locally and sends nothing. Its rules are teaching choices, not a built-in Overskill form feature or evidence that a reader's app behaves the same way.

1. State the field rules and what must stay

The sample has three fields:

• Quantity: a required whole number from 1 to 50. Blank means unanswered. This English-language sample accepts digits 0–9, including leading zeroes; it rejects decimal, signed and exponent notation.
• Project note: required text with at least one non-whitespace character. Keep its exact value when another answer needs correction, including case, punctuation, spaces and line breaks.
• Optional reference: may be omitted. Blank or whitespace-only text is not an error. A nonblank reference is sample text, not a successful lookup of an outside record.

Checking does not rewrite any field. Quantity can be interpreted after trimming surrounding spaces, but its entered text stays visible. An invalid 51 remains 51; it is not clamped to 50 or erased. Trimming the note to test whether it is empty does not authorize changing the note itself.

For your app, have the owner confirm the real field rules and retention policy. Record uncertain requirements as Unknown. A materials quantity, a phone number and a password may need different handling; the sample's range and exact-text policy are not universal defaults.

2. Try a quantity error in the local sample

Start with these answers:

1. Enter 51 in Quantity.
2. Enter Blue display stand in Project note.
3. Leave Optional reference blank and choose Check answers locally.

The summary says Correct 1 field. Both its Quantity link and the message beside the field say Quantity: enter a whole number from 1 to 50. Quantity still contains 51, the note still contains Blue display stand, and the optional reference remains empty.

The sample moves keyboard focus to the summary heading after this explicit Check. Activate its Quantity link next. The Quantity control should receive focus so the answer can be edited immediately. Seeing the page scroll near the control is not enough to establish that keyboard focus moved there.

A useful message identifies the affected answer in text and gives the known correction. These principles are explained in W3C's guidance on error identification and error suggestions. The specific range and wording here come from the sample's declared rules.

W3C's form-notification tutorial describes summary and field-level feedback. Its error-link technique explains a way to help people reach errors. This sample chooses a summary followed by links to controls; that is one focus policy to test, not a claim of accessibility conformance.

3. Correct one answer, then challenge the ready result

With Quantity focused, replace 51 with 12. Leave the other answers alone and check again.

The local result says Ready to review. Nothing has been sent. The quantity error disappears, the note remains exact, and the blank reference is labeled omitted. Focus moves to the result heading after the explicit Check. This result means the sample's local rules passed; it does not mean a workshop received an inquiry or a server saved a record.

Now clear Quantity without checking again. The old ready result must disappear immediately. The sample shows Answers changed. Check again., keeps focus on the field being edited, and leaves the project note unchanged.

Check once more. The new message is Quantity: enter a quantity from 1 to 50. Empty is unanswered, not zero. The note must still say Blue display stand.

Repeat the edit after a ready result for Project note and Optional reference. Each edit clears the previous check and its errors. Changing a value and then restoring the original text does not restore the old ready result; an explicit new Check is still required. The visible result then refers only to an explicit check of the current answers.

4. Compare retained answers with an erased note

The companion card includes a deliberately flawed reset-all state. It is an authored counterexample, not a recorded defect in an Overskill app.

Quantity: it starts as 51. After the quantity error, the expected value is still 51, beside a correction message. The bad state replaces it with an empty field.

Project note: it starts as Blue display stand. The person has not edited it, so the expected value remains Blue display stand. The bad state makes it empty too. That is the lost valid answer this exercise is meant to reveal.

Optional reference: it starts empty and stays omitted. Its blank value should not increase the error count or require a made-up reference.

The distinction is visible without diagnosing code. If your actual form loses the note, record the exact before and after values in the blank card. The symptom does not establish which component caused it or whether a proposed repair works. For help producing a repeatable sequence, use the app-bug reproduction guide.

5. Test more than the first successful correction

Check Quantity and Project note together with invalid or missing values. The sample should identify both fields, put Quantity before Project note in the summary, and provide a separate correction link for each. Activate both links using the keyboard. Confirm the focused control, the visible explanation, and the unchanged value of the other answer.

Keep these boundary checks with the main sequence:

• Empty or whitespace-only Quantity needs an answer. It must not silently become zero.
• 0, 51, 1.5 and 1e1 fail the declared quantity rules.
• 1, 50 and 0012 pass when the required note is present. Leading zeroes remain in the control.
• 12 also passes without removing the surrounding spaces from the entered text.
• A blank or whitespace-only note fails. A blank optional reference does not.

Try a note with two leading spaces, punctuation, a line break and two trailing spaces: Café display, blue; size A on the first line and Second line on the second. Compare the exact text after checking and correcting Quantity. A matching-looking summary is not sufficient if the underlying control lost spaces or a line break.

Use a phone-sized view as well as the keyboard. Read the labels, correction text and result without relying on color alone. If you test with a screen reader, record the actual tool, version and announcement. Focus observations or markup attributes by themselves do not establish that result.

6. Separate correction from leaving the page

Retaining answers during a correction and keeping a draft for another visit are separate promises. The standalone teaching sample has an explicit policy:

• Section links, including Back and Forward between sections of the same page, keep the current answers and check result.
• Leave the sample for Learn opens the Learn index. Returning after that departure starts with blank fields. Reloading also clears the sample.
• Reset sample explicitly clears the fields and results.

Try those paths separately. A section jump should not erase the note; a successful section-history test does not prove what happens after leaving the document.

A production form may need a different return or storage policy. Define that policy before testing it, especially if a person could lose substantial work. W3C's redundant-entry guidance addresses repeated entry within the same process, with exceptions; it does not create a general requirement to store answers between sessions. Use the interruption guide for the broader saved-request, sign-in and return journey.

7. Take one checked request to the existing app

Fill the blank half of the acceptance card for the actual form. Record its page, revision or Unknown, preview or published surface, permitted sample data, browser, device and date. Add the real rules and the intended leave/reload policy. Keep expected and observed values in separate columns, and leave unperformed checks marked Not tested.

For app changes in Overskill, use the editor's AI Prompt Builder. Help Chat is a separate support route, as described in Getting help in Overskill. Prepare the request around the affected form rather than starting a new app:

On [existing form and revision], check [reviewed field rules] when the
person chooses [the declared action]. Preserve answers they have not
edited, including [valid note] and an omitted optional [reference].
Keep invalid input visible so it can be corrected.

Identify each invalid field in text, explain the known correction,
and provide a reachable correction target using [our focus policy].
When an answer changes, remove the old ready result immediately.
A local check must not say that anything was received or saved.

Repeat the invalid-to-corrected-to-invalid sequence, two-error case,
exact-text checks, keyboard focus and phone review. Test our declared
section, exit and reload policy. Record the changed revision, actual
results and unknowns. Do not add storage or a submission workflow to
this correction request.

After a change, repeat the original failing case and the nearby passing cases on the actual revised app. A builder response is not the recheck. Keep server acceptance, draft persistence and assistive-technology results separate until each has its own evidence.