Individual HTML example · Obstruction

Contact form requires irrelevant purchase data

A fictional retailer’s only contact form requires an order number and rejects enquiries from people seeking accessibility information before purchase.

Customer-support obstructionPre-sale accessibility queryPricing

This is an original fictional comparison. It depicts no real business and is not a regulator finding, statutory category or legal safe harbour.

Pre-sale accessibility queryPricing

Contact form requires irrelevant purchase data

A fictional retailer’s only contact form requires an order number and rejects enquiries from people seeking accessibility information before purchase.

Potentially problematicContact customer care

Contact customer care. An order number is mandatory for every topic.. Required order number: Enter required order number. Question: Enter question. Enter order number

Neutral alternativeChoose an enquiry type

Choose an enquiry type. Pre-sale questions can be sent without purchase data.. Email address: Enter email address. Accessibility question: Enter accessibility question. Send accessibility question. Purpose and refusal effect, expanded: The form explains why “Send accessibility question” is requested and what happens if it is not used.

Why the first version can mislead: The route adds avoidable effort between the user’s stated intention and completion. In this pre-sale accessibility query example, the obstacle is: “An order number is mandatory for every topic.” Evidence should show whether the alternative remains usable and whether “Send accessibility question” reaches the represented state. Potential customers cannot obtain material support because the form assumes a completed transaction.

What a fairer design does: Ask only for information relevant to the enquiry and provide routes for pre-sale, account and order support.

Show annotated differences (4)
Potentially problematic version
  • An order number is mandatory for every topic.Why this state matters: The route adds avoidable effort between the user’s stated intention and completion. In this pre-sale accessibility query example, the obstacle is: “An order number is mandatory for every topic.” Evidence should show whether the alternative remains usable and whether “Send accessibility question” reaches the represented state. Potential customers cannot obtain material support because the form assumes a completed transaction.
  • Enter order numberReview prompt: How many steps, waits and channel changes separate “Enter order number” from the completed pre-sale accessibility query outcome?
Neutral alternative
  • Pre-sale questions can be sent without purchase data.Fairer design: Ask only for information relevant to the enquiry and provide routes for pre-sale, account and order support.
  • Purpose and refusal effect, expanded: The form explains why “Send accessibility question” 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: “Available routes are difficult to find, repeatedly loop or lack a viable escalation path”?
Review questions (3)
  • How many steps, waits and channel changes separate “Enter order number” from the completed pre-sale accessibility query outcome?
  • Which fields or permissions are required, what happens on refusal, and does the resulting state support this criterion: “Available routes are difficult to find, repeatedly loop or lack a viable escalation path”?
  • Measure the same task through the clearest available route: does the effort difference persist once “self-service that fully resolves the issue” is accounted for?
Side-by-side pre-sale accessibility query interface showing “Contact customer care” and the clearer alternative “Choose an enquiry type”.Provenance: Original hypothetical pre-sale accessibility query example created for this library; no real business, product or interface is depicted.

Complete practice context

How this example relates to Customer-support obstruction

Access to support needed to resolve a purchase, account, charge or right is hidden or burdened by unnecessary loops and dead ends. 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

Customer-support obstruction

Support bot loops without escalation

Billing supportAccount Management

A fictional subscription service routes every “charged after cancellation” message through the same three bot articles and offers no human or written case route.

Open this example

Account deletion obstruction

Deactivation presented as deletion

Social account settingsAccount Management

A fictional platform labels a control “Delete account”, but the confirmation only hides the profile and leaves data and reactivation available indefinitely.

Open this example

Account deletion obstruction

Deletion buried behind an unsupported ticket

Shopping accountAccount Management

A fictional retailer places account deletion behind six help pages and requires a support ticket containing an order number even for users who never ordered.

Open this example
Sources and provenance for this example

Evidence base

Sources

  1. An Ontology of Dark Patterns KnowledgeGray et al.; ACM CHI 2024 · Secondary · checked 2026-09-14 · DOI 10.1145/3613904.3642436; arXiv:2309.09640
  2. Competition and Consumer Amendment (Unfair Trading Practices) Act 2026Federal Register of Legislation · Primary · checked 2026-09-14 · C2026A00064