Map the repeated request
Start with a real customer journey, not a list of fields in isolation. A customer may give a contact telephone number while requesting a service, then be asked for the same number again when choosing a visit time. A checkout may ask for an address at delivery selection and present empty address boxes on the payment step. Record each step, who supplied each value, whether the later field asks for exactly the same information, and what decision the business makes with it. The crucial question is whether the person has already supplied the information in the same process and must type it again to finish. W3C's Redundant Entry criterion covers information previously entered by the user or provided to the user that is required again in that process. It says to populate it or make it selectable, subject to specific exceptions. This is a useful design audit even if a small business is not making a formal conformance claim. Keep the process boundary clear: a new visit next month is not automatically part of the original process. A review screen that displays the number for confirmation is different from an empty input demanding another entry. Interview staff about where repeated fields were added for a genuine operational reason rather than assuming every duplicate is accidental.
Choose how the earlier value appears
There are three practical patterns. First, keep the earlier value in an editable field when the later step genuinely needs it. Second, show a concise summary and an explicit Change action that returns the person to the right step without erasing later work. Third, offer a clearly labelled choice, such as using the delivery address already supplied as the billing address, when those details can legitimately be the same. W3C technique G221 gives examples of a checkbox that populates a shipping address from an earlier billing address and a later step that presents previously supplied business details for selection. This is guidance on one possible implementation, not a required widget. Do not silently copy one person's address into another recipient's field. If the later value has a different meaning, ask it separately and make the distinction visible. In a booking form, the customer's contact telephone and the technician's on-site contact can be different even if they often coincide. A choice labelled Use my contact number for the on-site contact is clearer than a hidden duplicate. Let the customer see which value will be used before committing.
Walk through a service booking
Imagine a repair business with four steps: describe the fault, give contact details, choose a visit, and review. Mei enters her name and telephone on step two. On step three the business asks who can open the door and which number the technician should call. The interface can show Mei's contact details as a selectable option and provide Different on-site contact as a separate route. If she selects herself, the saved visit contact is sourced from the earlier answer. If she chooses another person, the form asks only for that person's name and telephone. The review step shows the customer contact and on-site contact under separate labels, with a Change action for each. If Mei changes her own telephone, the system should decide and explain whether the selected on-site contact follows that change; it must not quietly leave a stale number or overwrite a deliberately different contact. On a failed submission, preserve the answers that remain valid, identify the affected field, and guide correction. This is an illustrative workflow, not a claim about a measured customer outcome. The acceptance test is that Mei can complete each valid route without retyping an unchanged value and can notice and correct a copied value before the booking is final.
Apply the exceptions narrowly
The W3C criterion has three exceptions: re-entry is essential, re-entry is required for security, or the previous information is no longer valid. Treat these as reasons to document, not as a convenient label for any extra confirmation field. Re-entering a concealed new password can be a security measure because the site cannot otherwise verify the user's intended string; an ordinary telephone field does not become a security measure merely because staff prefer two copies. An expired selection may need to be made again if the appointment slot is no longer available. An address that the customer deliberately changed is no longer the old answer. If a previous value is no longer valid, explain what changed and retain unrelated answers. Avoid asking for sensitive data twice just to reassure staff: it can increase exposure and error risk. The W3C understanding material also notes that a careless prepopulation design can leak personal information. A shared terminal, copied link, browser history, and server-side draft ownership all matter when deciding where temporary values live. Keep values tied to the right customer and process, clear them at the appropriate point, and review the design with the person responsible for privacy.
Set the data rule before building the screen
A clear interface depends on a clear data model. Give each value a purpose, source, and update rule: customer contact number, visit contact number, and the flag indicating whether the latter follows the former. Make the selected-copy action explicit rather than storing two unrelated strings that only happen to match today. Decide whether editing the source later updates the copy automatically, prompts for confirmation, or breaks the link. The answer should match the customer's mental model and be visible at review. In a multi-step web form, store draft state in a way that survives back navigation and an ordinary validation error, while preventing another user from retrieving it. If the application reloads a step from a server, verify it gets the current authorized draft rather than an obsolete client snapshot. If the process can be resumed, distinguish that feature from the WCAG same-process requirement; cross-session persistence raises additional privacy and account-control decisions. Product, engineering, and support staff should agree on field names because an internal field called phone is too vague to explain whether it belongs to the payer, recipient, or on-site person.
Test changes, errors and devices
Test a small matrix of realistic paths rather than clicking through only the default route. Start with a new customer whose billing and delivery details match, then one whose delivery recipient is different. Repeat with a booking where the on-site contact first matches and then changes. Use keyboard navigation and a screen reader to confirm the option to reuse information is named and its state is exposed; use touch to confirm the option is discoverable without relying on a hover hint. Navigate backward, correct the original value, then forward again. Trigger a validation error on an unrelated field and confirm earlier valid answers survive. Open the same process in two tabs and decide which draft version wins or how a conflict is shown. On a shared device, sign out or start another customer's process and verify the previous customer's details are not exposed. A concise record for each test should contain the starting values, action, expected carried-forward value, actual value, and whether the customer was told of any invalidated information. This makes the repair precise and repeatable.
Make the release decision
A useful release criterion is a completed journey with no unnecessary retyping, a visible route to change copied information, and no cross-customer exposure. If the business cannot state why a repeated field exists, remove the demand or make the earlier answer available before launch. If two fields have different operational meanings, name both meanings and give the customer a reuse option only where it is valid. If security or expiry genuinely requires re-entry, show the reason at the point of use and keep the rest of the process intact. Assign ownership for the data rule as well as the visible label: a page may look fixed while its server still uses a stale phone number. Review the customer confirmation and staff view together, because the customer may see a corrected contact while the work order retains the old one. This decision is more valuable than a generic promise that the form is accessible; it identifies the specific customer effort removed, the exceptions that remain, and the evidence needed to say the flow works.
Before you proceed
- Can the customer reuse or select the same valid detail at a later step?
- Can they inspect and change copied details before final submission?
- Are security and expiry exceptions documented for the specific field?
- Does the staff record receive the value shown in customer review?
