Design an appearance settings screen — system, light and dark

## Role and objective

You are a product designer and accessibility-aware UI specification writer. Produce a screen specification for an appearance settings screen that lets users choose among **System**, **Light**, and **Dark** modes.

Write for “[FILL IN: product team or implementation audience]”; this slot must be filled with the people who will use the specification. Do not invent a product name, platform, brand identity, visual style, or interaction model not supplied in the brief.

Your deliverable is a concise, implementation-ready specification organized as a screen list, components per screen, behavior per state, and design tokens. Completion means every appearance option, required interface state, keyboard behavior, screen-reader label, responsive constraint, and unresolved input is explicitly covered.

## Scope and given facts

In scope:

- One appearance settings screen.
- Three user-selectable appearance modes: **System**, **Light**, and **Dark**.
- The interaction and presentation needed to choose, display, and confirm the selected mode.
- Loading, empty, and error states.
- Keyboard operation and screen-reader labels.
- Responsive behavior, including the required viewport and zoom constraints.
- Date, number, currency, and address formats only if those data types appear on the screen; otherwise state that they are not applicable.

Out of scope:

- Designing unrelated settings screens.
- Inventing additional appearance modes, themes, palettes, branding, animations, or navigation destinations.
- Implementing code or asserting that a design has been tested when no test result is provided.

Confirmed facts are limited to the requested screen and its three modes. Use these unresolved slots:

- “[FILL IN: product or platform context]” — fill with the product, platform, or device context.
- “[FILL IN: brandAnchor]” — fill with the exact fixed brand description, or state “not provided.”
- “[FILL IN: accessibility jurisdiction]” — fill with whether ADA Title III or Section 508 governs, or state “not provided.”

Do not fill the appearance settings screen’s missing visual or technical details arbitrarily.

## Working rules

Use the following decision rules:

1. Treat **System**, **Light**, and **Dark** as distinct choices. If the product’s platform uses different terminology, preserve these labels unless “[FILL IN: approved labels]” supplies replacements.
2. If System mode follows the device or operating-system preference, describe that dependency only as a behavior to confirm unless the input supplies its exact source and update timing. Do not invent a synchronization mechanism.
3. If selecting an option applies immediately, specify the visible confirmation and persistence behavior. If confirmation is required, specify the confirmation control and the unsaved-change behavior. Because the input does not decide between these branches, mark the unresolved choice as “[FILL IN: apply behavior].”
4. Use the supplied brandAnchor wording verbatim wherever a fixed brand description is provided. If no brandAnchor is supplied, do not create one.
5. Set the accessibility target to **WCAG 2.2 AA**. Ask whether **ADA Title III** or **Section 508** governs the audience; do not assume either applies.
6. Require the layout to remain usable at **200% zoom** and in a **320px-wide viewport**, with no horizontal scrolling.
7. Specify keyboard focus order, visible focus indication, activation keys, selected-state communication, and how users return to or leave the screen.
8. Provide accessible names and state announcements for the mode selector and each option. Do not rely on colour alone to communicate the selected mode or theme.
9. Cover loading, empty, and error behavior. If an empty state cannot logically occur for this screen, state that it is not applicable and explain why rather than inventing empty content.
10. Include only confirmed date, number, currency, and address formats. If none appear, mark each as not applicable.

## Output structure

Produce the deliverable in this order:

1. **Screen list** — identify the appearance settings screen, its purpose, entry point as “[FILL IN: entry point]” if unknown, and exit behavior as “[FILL IN: exit behavior]” if unknown.
2. **Components per screen** — list the page title, explanatory text, mode selector, the three options, selected-state indicator, any save or confirmation control, and any navigation control. For each component, state its role, content, interaction, and accessibility name.
3. **Behaviour per state** — use subsections or a table for:
   - Loading
   - Empty
   - Error
   - Default or initial state
   - Each of System, Light, and Dark selection states
   - Keyboard focus and activation
   - 200% zoom and 320px viewport behavior  
   Mark unknown behavior with the relevant “[FILL IN: …]” slot.
4. **Design tokens** — provide a token table covering colour roles for both light and dark contexts, typography, spacing, borders, focus indication, control sizing, and responsive rules. Use “[FILL IN: token value]” where values are not supplied; do not invent hex codes, font names, or measurements.
5. **Format note** — state whether date, number, currency, and address formats are present; if present, leave each as “[FILL IN: format]” until confirmed.

Use tables for component inventories, state behavior, and design tokens. Keep the narrative limited to the purpose, interaction rationale, and unresolved decisions. Do not provide code.

## Style rules

Use a **hybrid** style. Use itemized lists and tables for screen inventory, component properties, states, accessibility requirements, and design tokens. Use short narrative paragraphs only for the screen purpose, the distinction between System, Light, and Dark behavior, and decisions that require a conditional branch. Keep the register precise and implementation-oriented. Avoid generic UX clichés such as “seamless experience,” “intuitive design,” “delight users,” and “best-in-class.”

## 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 specifies one appearance settings screen rather than unrelated settings or implementation code.
2. Confirm that **System**, **Light**, and **Dark** each have a distinct label, state, and behavior description.
3. Confirm that loading, empty, and error states are covered, including an explicit not-applicable statement where appropriate.
4. Confirm that keyboard focus order, activation, visible focus, and screen-reader labels are present.
5. Confirm that WCAG 2.2 AA, 200% zoom, and the 320px viewport with no horizontal scrolling are stated.
6. Confirm that the output uses the required sections: screen list, components per screen, behavior per state, and design tokens.
7. Check every factual statement against the supplied request; remove facts about the product, platform, brand, or theme that were added beyond the input.
8. Check every “[FILL IN: …]” slot, especially product context, brandAnchor, apply behavior, entry point, exit behavior, and token values; verify that none was filled arbitrarily.
9. Check that the work does not drift into unrelated settings, code, marketing copy, or unsupported implementation claims.
10. Confirm that any date, number, currency, or address format is either explicitly supplied, marked not applicable, or left as a slot.
11. Confirm that any conditional behavior identifies the condition instead of silently choosing one branch.
12. Confirm that the final response contains no invented visual token values, platform conventions, legal applicability, or test results.