Design form labels and instructions that remain available
Build a workshop-registration form with persistent labels, grouped questions, useful hints, clear requirements, and programmatic relationships, then check the task without relying on placeholders or proximity alone.
Keep each question understandable during entry
A label identifies the information a form asks for. A placeholder disappears when someone begins typing, so it is a poor place for the only instruction about what belongs in the field. Workshop registration may include contact details, attendance choices, and access requests; each question needs a clear purpose and an understandable relationship to its control.
Connect labels, hints, and groups
Keep labels visible and connect them programmatically to their inputs. Use a group description where several controls answer one question. Put necessary format guidance before the person encounters an error. Mark requirements consistently and explain what optional information will be used for. Avoid requesting sensitive detail merely because space exists on the form. Place the proposed solution beside a simpler alternative and ask what extra work each one creates. Count decisions the person must make, rather than decorative elements on the canvas. A useful control explains its scope before activation and its result afterward. If the design depends on someone remembering an instruction from a previous screen, move that instruction closer to the decision or remove the dependency.
Build a considerate registration form
Design fields for contact email, session choice, and an optional message about access arrangements. Write labels and hints that explain the requested information without demanding a diagnosis. Include a grouped set of session choices. Check that the hint and any error remain associated with the relevant control in the implementation. Keep a record of the starting conditions alongside the prototype. The same action can be easy with a familiar record and confusing with an incomplete one. Choose the record deliberately, then describe what would count as completion. Show the state immediately after the action as carefully as the initial view. A prototype that ends at the click cannot answer whether the person understands the result.
Repair visual and programmatic disconnects
If a floating label becomes too small or overlaps entered text, the presentation is undermining the question. If several controls share a vague label such as Details, their individual purpose may remain unclear. A nearby paragraph can look connected while lacking a programmatic relationship. Review both visible organization and the information available to assistive technology. Check whether a local fix creates a problem elsewhere. A longer label may clarify one choice but become clipped in another view; an extra confirmation may protect a destructive action but obstruct routine work. Carry the revision through the full example and its alternate route. Document the tradeoff explicitly so the next person modifying the design understands which behavior the change was intended to protect.
Review entry and correction together
Walk through the form with realistic answers, keyboard input, and appropriate assistive-technology checks. Ask whether the question remains understandable after entry and after an error appears. Preserve accepted answers during correction. The aim is a question whose purpose and instructions stay available throughout the task, rather than a pristine empty form that becomes confusing as soon as someone uses it.
Worked decision
Use an optional access-arrangements question that explains its purpose without requiring a diagnosis, and retain its label after the person starts typing.
References & further reading
Examples and exercises in this guide are original teaching scenarios.
