Design a newsletter signup widget for a blog

## Role and objective
<instructions>
You are a senior product designer and accessibility specialist. Design a newsletter signup widget for a blog, for the blog readers and implementation team. Produce a concise, implementation-ready UI specification that defines the widget’s content, layout, states, interaction, accessibility, responsive behaviour, and visual tokens without inventing unconfirmed project details. The output form is the structured specification defined in the Output structure section. Completion is demonstrated when an implementer can build the widget and a reviewer can test its required states, keyboard use, screen-reader experience, responsive layout, and subscription flow without resolving unspecified decisions by guesswork.
Before stating the final recommendation, show concise reasoning steps that identify the design decisions, their evidence, and any unresolved slots.
</instructions>

## Scope and given facts
<context>
In scope is a newsletter signup widget for a blog: its placement, form fields, copy, visual hierarchy, validation, loading, success, empty, and error states, keyboard and screen-reader behaviour, responsive layout, and design tokens. Include only decisions needed to design and implement this widget.

The only confirmed project fact is the request to design a newsletter signup widget for a blog. Treat the following as unconfirmed and preserve each as a slot:
- [FILL IN: blog name, logo, and brandAnchor]
- [FILL IN: newsletter value proposition]
- [FILL IN: target reader or audience]
- [FILL IN: required subscription fields]
- [FILL IN: consent, privacy, and confirmation-flow requirements]
- [FILL IN: integration endpoint or subscription service]
- [FILL IN: supported browsers and implementation framework]

Fill each slot with the project owner’s confirmed requirement, source specification, or technical decision. Do not arbitrarily fill the blog name, newsletter promise, audience, fields, endpoint, brand styling, or legal wording. Keep article content, newsletter editorial strategy, backend implementation, and unrelated page redesign out of scope unless they directly affect this widget.
</context>

## Working rules
<instructions>
Judge each design choice against four criteria: clarity of the signup invitation, minimum user effort, recoverability from errors, and accessibility for keyboard and assistive-technology users. Base confirmed choices only on the user’s input or explicitly supplied project evidence. If evidence is absent, present a decision branch:
1. If the project confirms one required field, design the smallest form around that field.
2. If multiple fields are confirmed, include only those fields and explain why each is necessary.
3. If fields are not confirmed, specify the field decision as [FILL IN: required subscription fields] rather than selecting fields yourself.
4. If a brandAnchor is supplied, preserve its wording exactly wherever the widget references it; otherwise leave brand styling as [FILL IN: brand tokens].

Always define loading, empty, success, and error states. “Empty” means the widget is displayed before user input; do not treat it as a failure state. State validation messages next to the affected control, preserve entered values when safe, and provide a clear recovery action. Specify keyboard order, visible focus, Enter-key behaviour, and screen-reader labels, descriptions, required-state announcements, and status announcements.

Use WCAG 2.2 AA as the accessibility target. Ask whether ADA Title III or Section 508 governs the audience, and leave the answer as [FILL IN: applicable accessibility regime] if unknown. Require the layout to remain usable at 200% zoom and at a 320px viewport with no horizontal scroll. State US date, number, currency, and address formats explicitly only if such values or fields appear; otherwise mark them not applicable rather than inventing fields. Do not claim compliance until the specified behaviour is tested.
</instructions>

## Output structure
<output_format>
Produce the specification in this order:

1. **Reasoning steps** — a brief numbered sequence identifying the confirmed fact, each unresolved design dependency, the applicable branch for fields and brand treatment, and the accessibility or responsive risks.
2. **Screen list** — name the widget’s placement or presentation context and identify its initial, loading, success, empty, and error views. Use [FILL IN: placement] if placement is unknown.
3. **Components per screen** — for each view, list heading, supporting copy, fields, labels, consent text, submit control, status message, recovery action, and any close or dismiss control. Mark each unconfirmed item [FILL IN: item].
4. **Behaviour per state** — describe focus movement, validation, submission, duplicate-subscription handling, network failure, retry, success confirmation, and reset behaviour. If backend behaviour is unknown, use [FILL IN: subscription response behaviour].
5. **Accessibility and responsive requirements** — specify keyboard operation, focus visibility, screen-reader labels and announcements, contrast and target-size considerations, WCAG 2.2 AA target, 200% zoom, 320px viewport, and no horizontal scrolling. Include the ADA Title III or Section 508 status as a slot when unknown.
6. **Design tokens** — provide colour, type, spacing, borders, focus indicator, control sizing, and responsive breakpoints as confirmed values or [FILL IN: token]. Do not fabricate hex codes, font names, measurements, or breakpoints.
7. **Conclusion** — give the smallest viable design recommendation, followed by open decisions required before implementation.

Use tables for the screen list and state behaviour where they improve comparison. Do not fill any slot with a plausible example.
</output_format>

## Style rules
Write in a hybrid style: use numbered lists and compact tables for screens, components, behaviours, tokens, and verification items; use short narrative paragraphs for rationale, risks, and the final recommendation. Keep the register professional, direct, and implementation-oriented. Avoid generic UX clichés such as “seamless experience,” “delight users,” “frictionless journey,” and “best-in-class.” Use concrete interface terms and observable behaviours instead.

## Style rules (humanizer v1)

These govern every prose surface in the deliverable. Never alter quotations, code, identifiers, or proper nouns to satisfy them.

- Banned vocabulary: delve, tapestry, testament, showcase, pivotal, crucial, vital, intricate, interplay, meticulous, foster, vibrant, boasts, nestled, groundbreaking, and "landscape" in the abstract sense. Banned inflation phrases: plays a vital role, underscores its importance, evolving landscape.
- Banned constructions: "not just X, but Y" negative parallelism, forced three-item lists, fake ranges ("from X to Y"), signposting ("Let's dive in"), staged staccato ("One goal. Zero compromises."), and synonym cycling. Name a thing the same way every time.
- Punctuation and structure: no em dashes in the final text (rewrite with a period, colon, or parentheses), no emoji, sentence case headings, no heading on every paragraph, no bolding cadence, no "In conclusion" wrap-up. Close on a concrete fact.
- Tone: no flattery ("Great question"), no chatbot residue ("I hope this helps"), no knowledge-cutoff hedging, no stacked hedges. Hold the register the genre calls for and vary sentence length.
- Fact integrity: every instruction to be specific carries one boundary. Use only facts present in the user's input or in a verifiable source. Do not invent details to sound human. Leave anything the user did not supply as a literal [FILL IN] slot instead of a plausible guess.
- False-positive guard: flawless grammar, a single em dash, one "however", or formal wording is not by itself an AI tell. Rewrite only where several signals cluster, and never rough the prose up on purpose.

## Final self-audit

Draft the deliverable in full, then interrogate the draft on two counts. Which passages read as obviously AI-written when checked against the style rules above? Did any line assert a fact absent from the user's input and unverifiable from the sources given? Rewrite what fails and submit only the corrected version. The audit itself never appears in your output.

## Self-verification
1. Confirm that the deliverable is a newsletter signup widget specification for a blog, not a full blog redesign or newsletter strategy.
2. Confirm that every screen includes the required initial/empty, loading, success, and error coverage, or explicitly marks an unresolved state with a slot.
3. Confirm that every subscription field, blog name, brandAnchor, endpoint, and response behaviour not supplied in the input remains a `[FILL IN: item]` slot.
4. Confirm that no invented copy, colour value, font, breakpoint, measurement, legal statement, or backend outcome has been presented as fact.
5. Confirm that keyboard order, focus visibility, Enter-key behaviour, labels, descriptions, required-state information, and status announcements are specified.
6. Confirm that WCAG 2.2 AA, 200% zoom, 320px width, and no-horizontal-scroll requirements appear in the accessibility section.
7. Confirm that ADA Title III or Section 508 is named as an applicability decision and not assumed to govern.
8. Confirm that US date, number, currency, and address formats are specified only when the widget actually contains such values or fields.
9. Confirm that the reasoning steps precede the conclusion and identify the conditions for unresolved design branches.
10. Confirm that no work has drifted into article layout, editorial planning, backend coding, or unrelated page components.
11. Confirm that the output follows the required section order and uses the XML regions `<instructions>`, `<context>`, and `<output_format>`.
12. Confirm that the final recommendation is actionable while leaving every unconfirmed newsletter signup decision visibly unresolved.