Stop asking clients for the same information

A client enters their mailing address at the start of onboarding. Two steps later, another form asks for it again. The team already has the answer, but the client must remember what they typed and repeat the work.

Removing that second entry sounds simple. The harder question is whether the earlier answer still means what the later step needs. A mailing address, a registered business address and an emergency contact’s address may all appear under the label “Address.” Reusing the wrong one can create a convincing mistake.

A useful collect-once workflow therefore begins with a question: which answer can we safely reuse here?

Browser autofill and process reuse solve different problems

Browser suggestions can help a person enter familiar details. Reuse within your intake process starts with information that person has already supplied during that process.

WCAG 2.2 addresses repeated entry through Success Criterion 3.3.7, Redundant Entry, at Level A. Information needed again in the same process must be populated automatically or available for selection, subject to exceptions for essential re-entry, security and information that is no longer valid. W3C’s guidance says browser autocomplete alone does not satisfy this criterion. It does not require retaining answers between sessions; it also excludes information supplied by another method, such as an uploaded résumé. W3C’s explanation of Redundant Entry.

A separate Level AA criterion, Identify Input Purpose, concerns making the purpose of covered inputs about the user identifiable in code. Whether a browser actually fills a field is not the test. W3C’s explanation of Identify Input Purpose.

These are useful distinctions when planning improvements. A field can have a clear technical purpose while the wider process still asks someone to repeat an answer. Review both the individual input and the journey around it.

Audit one repeated field from start to finish

The following worksheet is an editorial planning tool, not an accessibility conformance test. Use it to discover what a repeated question is doing.

• Question: What information does this step need?; Example answer: The client’s current mailing address
• Question: Whose information is it?; Example answer: The individual completing onboarding
• Question: Where did the earlier answer come from?; Example answer: Step one of this intake
• Question: Is that answer still valid?; Example answer: Ask the client to review it
• Question: How can the client change it?; Example answer: An edit action beside the address
• Question: Where will the confirmed answer go?; Example answer: The mailing section of the onboarding record

Specific answers expose hidden differences. “We need an address for the documents” leaves room for confusion. “We need the individual client’s current mailing address for correspondence” gives the team something it can check.

Include the destination because a correction has consequences. If the client changes their address at step three, decide which later documents should use the corrected version. Otherwise, the process may collect once yet reuse two conflicting answers.

Make reuse visible and correctable

Consider a hypothetical onboarding flow. Step one collects the client’s mailing address. Step three asks where to send correspondence.

A practical design could show the earlier address with an option to use it and an adjacent edit action. The client can confirm that it is still appropriate without typing it again. If a different correspondence address is needed, the interface should make that choice clear.

The label matters. “Use the mailing address you entered earlier” tells the client where the value came from. “Use saved details” leaves them to guess whether the system means this application, an older record or something else.

Now change the scenario: step three asks for an emergency contact’s address. The earlier client address is not automatically a suitable answer. The form should identify the other person and collect or select information appropriate to that person. A shared street address is possible, but it needs an intentional choice rather than an assumption.

This is the central design test: reuse should preserve both the value and its subject. A correct street address attached to the wrong person is still incorrect information.

Give every repeat a reason

Walk through a complete intake with the people who handle its output. Mark each question that appears more than once, then decide whether the later step needs confirmation, a changed value or genuinely different information.

For example, a review screen may need the client to confirm an address. That does not necessarily require a second empty text box. A question about another person may look repetitive while serving a different purpose. An outdated answer may require correction before it can be reused.

Record those decisions so the next form revision does not recreate the same uncertainty. Assign someone to resolve cases where teams disagree about what a field means or which answer should take precedence.

Start with one repeated address field. Trace its source, subject, validity and destination. Make the earlier answer available where appropriate, provide a correction route, and check that the final record reflects the client’s choice. That small exercise turns “collect once” into a concrete design decision your team can review.

How this connects to Inloom

Inloom’s approach starts with the documents a team already uses: review their questions, connect those that share a meaning, reuse appropriate known information and ask clients for the missing answers. The distinction between a mailing address and another person’s address is exactly why shared meaning needs review before reuse. The client forms overview explains this approach; it is not an accessibility conformance claim.

Book a demo to discuss the repeated questions in your own document process.