ux-patternslisted

# UX Patterns How an interface should behave, for whoever is writing it. Scoped to interaction: states, feedback, forms, and the cognitive-load laws behind layout decisions. | File | Read it for | |---|---| | This file | Web-first behavior rules | | `references/accessibility.md` | The conformance wiring every state needs. Read it alongside any state you build | | `references/mobile.md` | What changes on a phone | For a CLI or a terminal UI, load the **terminal-ux** skill if it is installed. Exit codes, stream discipline, TTY detection, and terminal screen-reader behavior have their own canon and are not covered here. Not covered here: type scales, color palettes, visual style, brand. Your design-system skill owns those. A rule that needs a specific palette or type scale is out of scope, so point at that skill rather than inventing values. Contrast appears in the accessibility reference as a conformance floor, never as a palette. Treat these as directional. A repo's established pattern wins over a rule here; match the surrounding code. Two markers override that: - **WCAG x.x.x (Level)** means a published conformance criterion. Not a preference, and not something a repo convention overrides. - A named law here is a label, and what sits under each one differs. Jakob's was coined by Nielsen as a summary of his own heuristics. Tesler's traces to an interview and carries a published counter-argument. Hick's is real experimental work, measuring something narrower than its usua