How to Design an Intake Form for Legal and Accessibility Constraints

A useful intake form for legal and accessibility constraints is not the longest one. It is the record that identifies the canonical brief, captures requirements that change downstream decisions, and routes unresolved questions to the right owner.

The form should distinguish new work, a change to an existing brief, and a related request before it collects specialist details. That distinction helps prevent parallel versions of the same project while preserving legitimate regional variants, new formats, and changed approval conditions.

Start with one canonical brief

Give every request a clear identity before asking for legal or accessibility details. Capture:

• Requester, role, team, and contact information
• Campaign, product, or project name
• Intended audience and market or region
• Deliverable type, channel, and format
• Desired deadline and deadline confidence
• Existing brief, project, or source-record link
• Request type: new work, change, or related request

Requester and organizational context help the team route questions and identify who can clarify missing information. Lawcadia’s legal intake guidance recommends collecting the submitting person’s name, role, department, and contact details. That supports a routing principle, not a universal creative-work schema.

Ask whether a source brief already exists before asking the requester to restate the project. If a matching record exists, make it canonical. The new submission becomes a related request, change request, or constraint update.

One accountable owner should maintain the brief’s identity, scope, links, and status. That owner does not need to decide every legal or accessibility question. They do need to keep the record coherent while specialist decisions are pending.

Capture constraints as decision records

Do not ask requesters for unrestricted legal or technical explanations when structured fields can route the issue more clearly. Each consequential constraint should record:

• Requirement: What must be true or avoided?
• Context: Which product, audience, market, channel, or deliverable does it affect?
• Evidence: Which policy, contract, test result, user need, or decision supports it?
• Owner: Who can interpret, approve, or revise the requirement?
• Status: Is it reported, routed, accepted, rejected, superseded, or unresolved?

This separates a requirement from its interpretation. “Legal restriction applies” is not an approval. “Needs to be accessible” is not evidence that the final experience meets a requirement.

Use grouped, purpose-driven fields instead of one large description box. Iowa State Bar Association guidance describes grouping related questions as a useful intake principle. Its legal-client context does not establish a complete schema for creative work.

Show legal fields only when relevant

Use trigger questions before displaying the legal section. Possible triggers include a regulated market, a product or service claim, personal information, licensing or usage rights, required disclosures, consent language, age restrictions, or a named legal-review dependency.

When a trigger applies, ask for the narrowest information that changes routing or production:

• Market, jurisdiction, or platform context
• Issue type, such as claim, disclosure, privacy, rights, consent, or licensing
• Exact copy, asset, or behavior affected
• Existing policy, contract, approval, or reference link
• Legal or privacy owner
• Review status and required decision date

Avoid collecting privileged material or sensitive personal information unless the organization has an approved process for handling it. The intake form should link to a controlled record when necessary. It should not become an uncontrolled archive for confidential advice.

SimplePractice’s intake guidance lists consent, privacy notices, agreements, and risk as context-dependent concerns in a different field. That example supports conditional prompts. It does not determine which obligations apply to a creative request.

Treat accessibility as a production input

Accessibility should be recorded as a requirement with context and a review path, not as an unqualified label. Ask what the deliverable must support and what conditions affect review:

• Product, platform, or channel
• Interaction type, such as reading, keyboard use, audio, video, or form completion
• Required formats, including captions, transcripts, alt text, audio description, or accessible documents
• Known user, assistive-technology, language, or communication needs
• Existing component or content standard
• Accessibility owner or reviewer
• Expected evidence, such as a content check, manual review, user test, or technical test
• Open questions and review status

These fields improve routing without claiming that the intake form proves conformance. For example, a form can record that captions are required. It cannot establish that the final captions are accurate, synchronized, complete, or suitable for the experience.

Guidance from MCD’s technical guidelines for accessible intake forms connects accessible form design with clearer communication and more accurate information collection. Apply that principle in two places: make the intake form usable, and capture accessibility needs that affect the requested deliverable.

Use conditional questions to reduce friction

Every required field should change a decision about routing, scope, approval, production, or timing. If it does not, make it optional, defer it, or remove it from the first screen.

A practical sequence is:

1. Ask whether the request relates to an existing brief.
2. Ask what changed or what new deliverable is needed.
3. Ask whether legal, privacy, rights, or accessibility conditions apply.
4. Show only the relevant specialist fields.
5. Ask for the responsible owner and evidence status.
6. Create a review state when the answer is incomplete or disputed.

This keeps the form shorter without hiding important dependencies. Practitioner guidance on legal intake also emphasizes gathering useful facts, routing them correctly, and avoiding unnecessary friction. Use that as a field-selection rule, not as proof that a particular form reduces abandonment or rework.

Detect duplicates without merging automatically

Similarity should create a review signal, not an automatic merge. Before opening a new brief, compare the submission with likely existing records using:

• Campaign, product, or project identity
• Audience and market
• Deliverable and channel
• Source brief or parent record
• Deadline and launch context
• Legal and accessibility constraints
• Requester and accountable owner

A likely match may be a duplicate request, a regional variant, a new format under the same campaign, a material scope change, or a separate project with similar language.

Create a duplicate-review state with three possible outcomes:

1. Link the submission to the canonical brief.
2. Create a related request that preserves the shared context.
3. Open a new brief and record why it is separate.

Do not force the requester to choose between “merge” and “new” when they lack enough context. Automatic matching can surface candidates. A responsible owner should make the merge decision.

Consider a hypothetical campaign request that arrives with a new delivery format, a regional legal restriction, and a requirement for captions and keyboard-accessible interaction. The form first searches for an existing campaign brief. If the campaign and audience match, the submission links to that brief, records the new deliverable and constraints, and routes unresolved questions to named owners. If the objective or approval path differs materially, it opens a related brief while preserving the relationship.

Preserve wording, ownership, and change history

A linked request is not a replacement for history. Keep the original wording, normalized values, change author, timestamp, affected field, decision owner, and decision status. A constraint ledger connected to the canonical brief shows what changed without erasing the earlier requirement.

Use explicit states such as reported, needs clarification, routed, accepted, rejected, superseded, and unresolved. “Unresolved” matters because it tells production teams that a requirement has been noticed but not yet interpreted or approved.

A form can improve record integrity and routing. It cannot provide legal advice, establish privilege, prove regulatory compliance, or demonstrate accessibility conformance. Those decisions remain with the appropriate legal, privacy, accessibility, product, or content owners.

The operating rule is simple: use one canonical brief for one coherent piece of work, attach related requests when they share that identity, and create a separate decision record whenever a constraint, owner, scope, or approval condition changes.

Teams that need to evaluate capture, triage, execution, and reporting can choose a tool for creative request intake. When a request reaches accessibility review, review accessibility at the component boundary to distinguish shared-component evidence from product-level verification.