Forced disclosure or excessive data request
Excessive details for product comparison
A fictional comparison tool requires occupation, exact birth date, mobile number and marketing preference before showing the plans that are available in a postcode.
Individual HTML example · Forced action
Exact birth date required for a delivery estimate
A fictional furniture shop requires a visitor to disclose an exact birth date and mobile number before showing whether delivery is available to the entered postcode.
This is an original fictional comparison. It depicts no real business and is not a regulator finding, statutory category or legal safe harbour.
Exact birth date required for a delivery estimate
A fictional furniture shop requires a visitor to disclose an exact birth date and mobile number before showing whether delivery is available to the entered postcode.
Tell us who you are first. Birth date and mobile number block a postcode-based availability estimate.. Exact date of birth: Enter exact date of birth. Mobile number: Enter mobile number. Delivery postcode: Enter delivery postcode. Submit personal details
Check delivery availability. The estimate uses the postcode; contact details remain optional until booking.. Delivery postcode: Enter delivery postcode. Show delivery estimate. Purpose and refusal effect, expanded: The form explains why “Show delivery estimate” is requested and what happens if it is not used.
Why the first version can mislead: The additional dependency controls access to the pricing goal. The panel states: “Birth date and mobile number block a postcode-based availability estimate.” Reviewers need to establish whether “Submit personal details” is necessary for the selected task or pressures the user into a separable action. The visitor must disclose identity and contact information that is unrelated to a preliminary delivery-availability check.
What a fairer design does: Use the postcode for the estimate, explain any genuinely necessary field and defer contact details until the visitor asks to book or save it.
Show annotated differences (4)
Potentially problematic version
- Birth date and mobile number block a postcode-based availability estimate.Why this state matters: The additional dependency controls access to the pricing goal. The panel states: “Birth date and mobile number block a postcode-based availability estimate.” Reviewers need to establish whether “Submit personal details” is necessary for the selected task or pressures the user into a separable action. The visitor must disclose identity and contact information that is unrelated to a preliminary delivery-availability check.
- Submit personal detailsReview prompt: What functional need makes “Submit personal details” necessary for the furniture delivery estimate goal, and can that need be met with less disclosure or commitment?
Neutral alternative
- The estimate uses the postcode; contact details remain optional until booking.Fairer design: Use the postcode for the estimate, explain any genuinely necessary field and defer contact details until the visitor asks to book or save it.
- Purpose and refusal effect, expanded: The form explains why “Show delivery estimate” is requested and what happens if it is not used.Review prompt: Which fields or permissions are required, what happens on refusal, and does the resulting state support this criterion: “Personal data is mandatory or refusal blocks a desired goal”?
Review questions (3)
- What functional need makes “Submit personal details” necessary for the furniture delivery estimate goal, and can that need be met with less disclosure or commitment?
- Which fields or permissions are required, what happens on refusal, and does the resulting state support this criterion: “Personal data is mandatory or refusal blocks a desired goal”?
- Could the stated purpose make this dependency genuinely necessary under the boundary “Data evidently required for delivery, payment, security, age, safety or law”, and what product evidence would demonstrate that necessity?
Complete practice context
How this example relates to Forced disclosure or excessive data request
Access or progression is conditioned on disclosing personal information that appears unnecessary, excessive or used for an insufficiently explained secondary purpose. This is a design and research taxonomy for learning and evidence review, not a statutory offence label or an automatic finding that an interface is unlawful.
The full guide explains inclusion and exclusion criteria, potential harms, fairer design, evidence questions and separate Australian legal information layers. The example page isolates one scenario so it can be shared and discussed without reproducing the complete library on one page.
Continue comparing
Related examples
Open this example
Automatic attention capture
Autoplay overrides a session limit
A fictional video service starts another clip when a user’s chosen twenty-minute limit is reached and hides the leave action behind a full-screen recommendation.
Automatic attention capture
Infinite catalogue without progress cues
A fictional marketplace continuously inserts new products and removes pagination, position and viewed-item markers while promotional prompts follow the shopper.
Sources and provenance for this example
Evidence base
Sources
- Dark commercial patternsOrganisation for Economic Co-operation and Development · Secondary · checked 2026-09-14 · OECD Digital Economy Papers No. 336
- Competition and Consumer Amendment (Unfair Trading Practices) Act 2026Federal Register of Legislation · Primary · checked 2026-09-14 · C2026A00064