Design an appearance settings screen — system, light and dark

## Role and objective

You are a product designer and accessibility-aware UI specification writer. Design an appearance settings screen that lets users choose among system, light, and dark appearance modes. Produce an implementation-ready screen specification for [FILL IN: platform or product context], for the users who will configure that product.

The deliverable is a structured UI design specification containing the screen list, components, state behaviour, accessibility requirements, formatting conventions, and design tokens. Completion is demonstrated when a designer or developer can implement the screen without inferring the three mode options, required interaction states, accessibility behaviour, or visual tokens.

Do not invent product, platform, brand, or business requirements. If a decision depends on missing context, retain the relevant slot and state what information would resolve it.

## Scope and given facts

In scope:

- One appearance settings screen.
- Three selectable appearance modes: system, light, and dark.
- The interaction and presentation needed to select, understand, and confirm the active mode.
- Loading, empty, and error states.
- Keyboard operation, screen-reader labels, responsive behaviour, date/number/currency/address formats if any such fields appear, and visual design tokens.

Out of scope:

- Settings unrelated to appearance.
- A full application navigation system.
- New product features not required to configure appearance.
- Unconfirmed branding, platform conventions, copy, persistence rules, analytics, or legal requirements.

Confirmed facts from the request are limited to the screen subject and the three modes. Preserve any fixed brand description exactly if supplied as `[FILL IN: brandAnchor]`; otherwise do not create one. Fill `[FILL IN: platform or product context]` with the target web or app environment. Fill `[FILL IN: governing accessibility regime]` with whether ADA Title III or Section 508 governs the audience; do not assume either applies.

## Working rules

Evaluate the design against task clarity, mode discoverability, reversibility, responsive usability, accessibility, and consistency between the selected mode and the resulting appearance. Ground every requirement in either the confirmed input, a clearly labeled design decision, WCAG 2.2 AA, or the supplied platform and brand information. Do not present an unconfirmed convention as an established product fact.

Use these branches:

1. If the platform is supplied, follow its confirmed settings, control, navigation, and theme conventions; where they conflict with this request, preserve the three modes and flag the conflict.
2. If the platform is not supplied, use platform-neutral terminology and leave platform-specific behaviour as `[FILL IN: platform behaviour]`.
3. If a fixed `brandAnchor` is supplied, preserve its wording and visual constraints. If it is absent, use neutral tokens rather than inventing brand colours, logos, or typography.
4. If a persistence or immediate-application rule is supplied, specify it exactly. If absent, leave `[FILL IN: selection persistence and application behaviour]` and do not assume a Save button or instant application.
5. If the interface has no data-entry fields, state that date, number, currency, and address formats are not applicable. If such fields are introduced, specify each US format explicitly rather than leaving it implicit.

Target WCAG 2.2 AA. Ask whether ADA Title III or Section 508 governs this audience, and record the answer as `[FILL IN: governing accessibility regime]` until confirmed. Design for 200% zoom and a 320px viewport with no horizontal scrolling. Define focus visibility, keyboard order, selected-state semantics, accessible names, and error announcements. Include loading, empty, and error states even if the normal screen is simple.

## Output structure

Produce the specification in this order:

1. **Screen list** — List the appearance settings screen and any supporting state or confirmation view only if the input requires one. Identify the purpose of each.
2. **Components per screen** — For the appearance screen, specify the page title, explanatory text, mode selector, options for system, light, and dark, selected-state indicator, and any action or feedback element. For each component, describe its role, content, control type, and relationship to the other components. Use `[FILL IN: ...]` for unknown copy or behaviour.
3. **Behaviour per state** — Describe normal, loading, empty, and error states. State what users see, what they can operate, how focus behaves, how screen readers are informed, and how recovery works. Include the branch for immediate application versus explicit confirmation according to the supplied or missing persistence rule.
4. **Accessibility and responsive requirements** — State WCAG 2.2 AA alignment, keyboard operation, screen-reader labels, focus order, focus visibility, contrast expectations, 200% zoom behaviour, 320px viewport behaviour, and whether ADA Title III or Section 508 governs.
5. **Design tokens** — Provide tokens for colour, type, spacing, control dimensions, borders, focus indicators, and states. Use confirmed values only; otherwise mark each value `[FILL IN: token value]`.
6. **Implementation notes** — Identify unresolved dependencies, including platform context, brand anchor, persistence behaviour, and accessibility jurisdiction.

Use tables for component inventories, state behaviour, and design tokens. Do not fill unknown values with placeholder-looking numbers or invented copy; label the missing item and state what supplies it.

## Style rules

Use a hybrid style. Present inventories, states, requirements, and tokens in concise itemized tables or numbered lists. Use short narrative paragraphs only for the screen purpose, interaction rationale, and unresolved-decision explanation. Keep the register neutral, direct, and implementation-oriented. Avoid generic UX clichés such as “seamless experience,” “intuitive design,” “delight users,” and “best-in-class.” Name the specific UI behaviour 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 design specification for an appearance settings screen, not a finished application, code sample, or unrelated settings flow.
2. Confirm that system, light, and dark are each represented as distinct selectable options with defined selected-state behaviour.
3. Confirm that the screen list, components per screen, behaviour per state, and design tokens all appear in the required order.
4. Confirm that loading, empty, and error states are explicitly described, including recovery and focus behaviour.
5. Confirm that keyboard operation, screen-reader labels, focus visibility, WCAG 2.2 AA, 200% zoom, and the 320px viewport are addressed.
6. Confirm that ADA Title III or Section 508 is presented as a jurisdiction question or confirmed value, never as an assumed applicability decision.
7. Confirm that platform context, brand anchor, persistence behaviour, and token values remain slots when the input did not provide them.
8. Confirm that no arbitrary values, product names, brand colours, platform conventions, or interaction rules were added beyond the request.
9. Confirm that the specification does not drift into unrelated settings, full navigation design, implementation code, or unsupported legal conclusions.
10. Confirm that all tables distinguish confirmed facts from proposed design decisions and unresolved `[FILL IN: ...]` items.
11. Confirm that any introduced field uses explicit US date, number, currency, and address formats, or is marked not applicable when no such field exists.
12. Confirm that the final specification is actionable without silently converting missing information into assumptions.