Persistent labels, useful hints, and appropriate controls reduce uncertainty before an error occurs.
By the end: design a small booking form with clear field identity, constraints, and a predictable submission outcome.
Ask only for necessary information
Studio Desk needs a guest name, an email for the receipt, and a requested seat count. This demo has three available seats. Explain constraints near the field before someone encounters an error. Do not collect extra data simply because the database has columns for it.
Use a control suited to the value. An email input can help a mobile keyboard choose useful characters, but it cannot prove an address is deliverable. A seat count should not silently accept a fraction or a number beyond capacity. Client validation helps interaction; the server must still enforce real business rules.
Explain each requested value before asking for it
Imagine arriving at the Clay basics form with a guest's name and a request for two places. Before typing, you need to know which session the form concerns, what each field expects, and what activating Reserve seats will mean. The session heading and availability statement establish the context. The field names identify the requested values. A useful form gives those answers before submission, rather than requiring a failed attempt to reveal basic constraints or the identity of an unfamiliar field.
Separate field identity from instructions about the value. Guest name answers what to enter. Use a fictional guest name answers how to use this demonstration safely. A value such as Mina Hart is neither of those things; it is the current draft. When these roles occupy one disappearing placeholder, entering the value removes part of the instruction. Keeping the identity and useful instructions outside the input allows someone to review a completed form without reconstructing which prompt appeared in each empty box.
Email identifies the field, the hint explains how to use this fictional demonstration, and the bordered text shows the current draft. The sample is static text, not an input. None of these roles proves that a message has been delivered.
The two forms request the same name, email, and seat count, but their visible explanation differs. The reference relies on placeholders for visual field identity while retaining programmatic labels. That means the fields are not unnamed controls, yet a sighted reader loses their visible prompts after typing. The selected form keeps visible labels and hints. Distinguish these two repairs when reviewing a form. An accessible name available to software does not automatically provide a persistent visible label on the page.
Read the static filled examples below as if you were checking someone else's draft. In one, [email protected] appears without a nearby visible field name. In the other, Email remains above it, with the instruction to use an invented address. The string is identical. The difference is what evidence remains after entry. This matters when a person returns after an interruption or checks several similar values. It does not require assuming they forgot how to use a website or cannot recognize an address.
What remains visible after typing
Static filled examples · action names are text, not submission controls
Both samples contain the same draft. The left reproduces the loss of visible prompts after placeholders disappear; its live counterpart still has programmatic labels. The right keeps visible names and hints. Text is 18 px here, rather than the live inputs' 17 px.
Seat count needs a constraint as well as an identity. The local capacity is fixed at three, and the accepted strings are exactly 1, 2, or 3. A hint can state that limit before someone tries four. The demonstration uses a text field with a numeric input hint rather than a menu that prevents every other entry. A numeric keyboard suggestion does not enforce the rule. The validator still decides whether the actual string belongs to the accepted set.
Consider a different service that asks for a telephone number only because an old template included one. A clearer label would not justify that collection. First establish what task requires the value and what happens if it is missing. For Studio Desk, keep the fictional name, invented address, and seat request as the bounded teaching task. Do not add real contact details to test realism. The form creates local display feedback, and its wording must not imply that a person received a message or a place was booked elsewhere.
Try the interface
Your task: Use a fictional draft preset. Type into both forms and watch what happens to the reference placeholders. Submit valid details and inspect the local receipt.
Complete and repair a booking form
Studio Desk demonstration. Actions affect this page only, not a real booking, account, or payment.
Reference booking form
Clay basics
Saturday, 14:00 · 3 places available
Selected booking form
Clay basics
Saturday, 14:00 · 3 places available
Draft condition
Stated rule
Guest name
1–60 characters after trimming
Email
Bounded email-like format; no delivery check
Seats
Exactly 1, 2, or 3
Invalid submit
Preserve draft and report a problem
Valid submit
Show a local receipt only
Complete validation rules and outcomes remain embedded offline.
Use fictional details. Presets replace both drafts and reset receipts/errors; editing changes only that form. Validation starts on submit, then reported problems update during correction. The email rule is a bounded teaching format check, not delivery verification. Each successful submission creates only a local display receipt.
Follow a draft through editing and submission
Choose Valid fictional guest in the working form comparison. Both drafts become Mina Hart, [email protected], and 2. Before pressing Reserve seats, inspect the feedback. A valid-looking draft is not a submitted receipt. Submit the selected form and read the local receipt naming two seats and Mina Hart. The reference has not submitted merely because the selected side did. This separates shared example setup from independent form actions, which is necessary when comparing how the two treatments support the same task.
Edit the selected name to Jo Park after that receipt appears. Only the selected draft changes, and its previous acceptance state clears. Because that form has already been attempted and the new details are valid, its status says the details are ready and asks for submission to create a local receipt. It does not silently update an already accepted booking. Submit again and inspect the new name in the receipt. The reference should still contain the original preset values throughout these one-sided edits.
A valid draft is not yet a receipt
Worked local sequence · no request or inventory service
Action
Selected form
Reference form
Valid fictional guest preset
Mina Hart; invented email; 2 seats; no receipt
Same values; no receipt
Submit selected
Local receipt for Mina Hart
No receipt
Edit selected name to Jo Park
Jo Park draft; details ready; submit again
Mina Hart draft; unchanged
Submit selected again
Local receipt for Jo Park
No receipt
Incomplete email preset
Mina Hart; mina; 2 seats; no errors yet
Same replacement draft; no errors yet
Submission changes the selected form's acceptance feedback; editing clears that acceptance. A preset replaces both drafts and resets both forms' feedback. The reference never submits as a side effect of submitting the selected form.
Now choose Incomplete email. This replaces both drafts, including your edited name, and clears their receipts and attempt states. The new email is mina. Before submission, neither form reports a validation failure. Submit the selected form and inspect its summary and field message. The guest name and seat count remain available. A preset is therefore a replacement of the whole comparison input, not an action that repairs only the currently focused field or merges new values with old ones.
The selected summary receives focus after a failed submission. Follow its Email link to reach the corresponding input, then replace mina with [email protected]. During correction, the reported errors update, but focus should remain in the field. Once the draft satisfies the rules, the status describes readiness rather than a completed receipt. Submit to create that receipt. This sequence makes the difference between a corrected draft and an accepted local action observable instead of hiding both behind a success-colored border.
Repair the email without replacing the other values
Static failed-submit state · selected form
Check these details
Email: Enter an email with a name and domain, such as [email protected].
After failed submit, the selected summary links to Email and receives focus. Correcting the address removes the error while focus stays in the field. The repaired draft still needs submission to produce its local receipt. This static specimen cannot receive focus.
Repeat with Four seats, only three left. Check that the name and email are already supplied, then submit and inspect the seat error. Replace 4 with 3 without retyping the valid values. This tests whether the form retains useful work and locates the remaining repair. Count neither the red borders nor the number of messages as success measures. The task is to recognize the capacity constraint, change the requested quantity, and distinguish a corrected draft from the resulting local receipt.
The trace below is a complete local sequence, not a simulated server conversation. No request becomes pending, no payment is taken, and no email leaves the page. A real booking service would add a server decision that could reject capacity even after a client accepted the draft. Keep that missing stage explicit when applying the lesson elsewhere. This comparison teaches visible identity, stated constraints, and correction behavior; it does not demonstrate reliable inventory allocation or persistence across leaving and reopening the page.
Keep identity visible while editing
A placeholder disappears when a value is entered. It can show an example, but it is a weak substitute for a persistent visible label. The reference form intentionally relies on placeholder text visually; it still has programmatic labels so the comparison does not require operating unnamed controls.
The revised form keeps labels and hints visible. Error text can refer to those same names. Inputs preserve entered values after a failed attempt. This small validator accepts a bounded email-like format; it is neither full email syntax validation nor a check that a person owns the address.
Distinguish an input aid from the acceptance rule
A field can help someone enter a value without proving the value is useful. The email field has an email input type, which may affect keyboard suggestions in some browsers. The form suppresses the browser's normal submission validation and uses its own teaching rules. Its email-like check requires non-space text on both sides of an at sign and a dot in the domain portion, with at most one hundred JavaScript string units overall. Passing that check supplies no evidence of mailbox ownership or delivery.
The custom email check rejects a raw address string containing a trailing space, but the browser acts first in this form. A native email input removes leading and trailing ASCII whitespace from its value before the change handler reads it. Disabling browser submission validation does not disable that normalization. An internal space, as in mina @example.invalid, remains and fails the custom check. The name rule instead explicitly trims its received value before checking length. Distinguish the raw validator argument from the value the interface can actually supply.
Whitespace has different rules in these two fields
Raw validator arguments, before any browser normalization
Field and raw string
Local result
Reason
Name: "␠␠Mina Hart␠␠"
Pass
Trimmed name is Mina Hart, within 1–60 string units
These raw strings go directly to the custom validators. The name rule trims; the email rule does not. In the actual form, the browser removes leading and trailing ASCII whitespace from the email input first, so the trailing-space rejection shown here is not a live-control prediction. Each ␠ marks one ASCII space; quotation marks are notation. Format acceptance proves no delivery.
JavaScript string length is not always the number of visible characters a reader perceives. Some symbols occupy two units, and a visible accented letter can sometimes be represented by more than one unit. The name input also has an entry-length limit of sixty, while validation examines the trimmed result. You do not need programming experience to use the form, but you should avoid interpreting this technical bound as a universal cultural rule about how long a legitimate person's name may be.
The seats field illustrates a narrower accepted language. The string 2 passes, but 02, 2.0, and a space followed by 2 do not. They might all suggest the same quantity to a human, but the validator accepts only the three exact single-character strings. Its numeric input hint does not convert them into numbers. The input's two-character entry limit also does not enforce capacity: 4 fits within that length yet fails the seat rule. Separate entry assistance, length limits, and business constraints when explaining a field.
Seat quantities are accepted as exact strings
Constructed input cases · quotation marks are notation, not input
Seat string
Result
Intermediate reasoning
"2"
Pass
Exactly one accepted character
"02"
Fail
Two characters; no conversion to 2
" 2"
Fail
Leading space remains
"4"
Fail
One character but outside 1, 2, 3
"2.0"
Validator rejects
Also longer than the live input entry limit of 2
The validator does not convert numeric-looking text into a quantity before checking. A two-character input limit and a numeric keyboard hint cannot enforce the exact set of 1, 2, or 3. All failures receive the same seat-repair message in this bounded model.
Try this distinction with the selected form using only invented details. Start with Valid fictional guest, change the seats to 02, and submit. Predict the field message before reading it. Replace the value with 2 and observe that the error resolves without creating a receipt until submission. Then use mina @example.invalid, with a space immediately before the at sign, and submit again. Compare which rule failed and whether the good values survived. These are format experiments, not attempts to discover a real address or bypass a booking service.
In a real product, decide which harmless variations to normalize and explain consequential limits early. A select menu with three options could prevent some seat-format mistakes, while a free entry might suit a different quantity range. Neither control choice proves that three places remain at submission time. Likewise, an email hint can explain purpose without promising delivery. The useful question is what evidence the interface has obtained at each stage and which additional decision another system would still need to make.
Explain what submission means
The action should name the result. "Reserve seats" communicates more than "Continue" if it actually completes a reservation. If there is another review or payment step, say so instead of claiming completion early. After success, show enough identifying information to remove uncertainty.
These examples issue local demo receipts only. Use the fictional presets rather than real contact details. No input is uploaded or stored across reloads. Presets replace both forms and reset their attempt state; editing one form does not modify the other.
Make the outcome as specific as the action
Reserve seats names a consequence, but the surrounding demonstration limits that consequence to a local receipt. Read the actual result after a valid submission. It names the requested seats and trimmed guest name, and says nothing was sent to the invented address. This is more precise than a generic success banner because it lets you check which draft produced the outcome. It still does not establish that any workshop inventory changed. A receipt-like visual treatment cannot supply evidence that the implementation never obtained.
Compare a draft containing a name with surrounding spaces against the name printed in the local receipt. The validator uses the trimmed name, and the receipt displays that trimmed name, while the draft is not rewritten into a new saved record. These distinctions are small enough to miss in an empty-form screenshot. A filled-state review should ask whether the displayed outcome matches the values used for acceptance and whether later editing is clearly a new draft action rather than an invisible update to a previous result.
The result names the submitted local values
Static successful-submit example · not a real booking receipt
Clay basics
Guest name draft
" Mina Hart "
Quotation marks expose surrounding spaces; they are not part of the input.
Demo receipt: 2 seats for Mina Hart. Nothing sent to [email protected].
The name shown in this local receipt is trimmed. The draft need not be rewritten to display that result. The explicit Nothing sent statement prevents the receipt's appearance from implying email delivery or a real inventory reservation.
The static outcome specimens below deliberately separate Details are ready from Demo receipt. Readiness means no current field violates the bounded validator after an attempt. It is an invitation to submit, not evidence of completion. The receipt follows a successful submit. Neither statement says Email delivered. If a service actually needed delivery confirmation, it would require evidence beyond accepting an address-shaped string. Do not improve the copy by replacing a limited but true statement with a more reassuring claim the system cannot support.
Before deciding that persistent labels solve the whole form, repeat a realistic interruption. Enter the fictional preset, move your attention to the session time, then return and identify each value without clearing it. Next submit an invalid seat count and repair it through the selected summary. These tasks examine different mechanisms. The first uses visible field identity; the second uses error navigation and retained work. Because the selected form improves both labels and feedback, a faster combined attempt would not isolate the effect of labels alone.
Correction and completion produce different feedback
Static status comparison · same Mina Hart draft and 2 seats
Corrected after an attempt
Details are ready. Submit to create a local receipt.
Next action: Reserve seats
Successfully submitted locally
Demo receipt: 2 seats for Mina Hart. Nothing sent to [email protected].
Editing again clears this acceptance feedback.
Both states can have identical valid values. The difference is whether a successful submission followed the last edit. Recognizing valid data is not the same operation as creating the local display receipt, and neither operation verifies delivery.
Observe the reference too, rather than assuming that missing visible labels make every task impossible. An experienced reader may identify an address-shaped value and complete this short form. The weakness becomes clearer with similar-looking values, interruptions, unfamiliar fields, or a need to correct a specific entry. Record that specific difficulty if it occurs. A technical check can verify that a label is associated with an input, while a task observation can reveal whether the visible explanation is sufficient. Those are different kinds of evidence.
For transfer, consider a settings form that changes where workshop updates will be sent. Keep Email as the persistent identity, state the actual purpose beside it, and choose an action label matching whether it saves directly or opens a review. Preserve the old accepted address until the service acknowledges a change, if that is the real contract. Use an invented address for any practice specimen. This lesson's immediate local receipt cannot answer how that service should handle pending requests, failed delivery, concurrent edits, or reopening the page later.
Exercises
Fix a disappearing field name
An entered value replaces the only visible word "Email." Why is an associated hidden label not the entire repair?
Hint
Programmatic identification and visible identification serve overlapping but different users.
Worked comparison only. These drawings are explanatory content, not active form controls or service promises.
Need
Repair
Programmatic name
Associated label
Visible identity while typing
Persistent visible label
Example format
Separate hint or placeholder
One label can support both visual and programmatic access.
Retain the programmatic label and make the visible label persistent. A hidden name helps some assistive-technology use but does not help a sighted reader who forgets which value belongs to which field. Keep examples or format hints separate from the label.
Separate format from delivery
An email passes this form's format check. Can the interface promise the receipt has reached the guest?
Hint
What evidence has the form actually obtained?
Worked answer
Check
Does not prove
Format accepted
Mailbox exists
Request accepted
Email delivered
Message delivered
Guest has read it
Feedback should match available evidence.
No. It has only accepted an email-like string. A real system would need a successful submission and evidence about delivery, and even transport acceptance is not proof the person read the message. Use wording such as "Booking received" when that is what the system knows.
Sources and further reading
Selected guidance and technical definitions were reviewed, not a complete usability literature or accessibility audit. The interfaces are original teaching examples. They do not establish measured improvements in task performance. These optional links are not runtime dependencies.