web-frontendlisted

# Web frontend A web UI is used by people and increasingly by browser agents, on browsers and devices you don't control. It must be operable, predictable under slow or overlapping requests, and verified in the browsers the product actually targets. ## Always - **Follow the project's architecture.** Keep its layering (for example FSD), its state manager and data-fetching layer, and its component library and design tokens. A new screen copies an existing screen's structure. Don't introduce a second state or styling approach. - **Browser targets come from the project** (`browserslist`, CONTRIBUTING, CLAUDE.md), not from memory. Features outside them need a fallback or the user's agreement. ## Semantics and accessibility: the practical minimum - Use native `button`, `a href`, `input`/`select`/`textarea` and `form`, not clickable `div`s. Links navigate; buttons act. - Every control has an accessible name: a visible `label`, or `aria-label` when there is no visible text. Icon-only buttons included. - States and errors are exposed: - `disabled`, `aria-expanded`, `aria-pressed`, `aria-invalid`; - error text linked with `aria-describedby`; - async status announced via `aria-live` where the user would otherwise miss it. - **Keyboard:** everything works by keyboard, focus is visible, and it moves deliberately (into dialogs, back to the trigger on close, to the first error on submit). No focus traps outside modals. - Logical headings (one `h1`, no skipped levels for styling) a