Design Knowledge Base
Community-maintained principles reviewed before publication and retrieved as Agent design constraints.
ARIA Component Contract
Before styling a custom interactive component, define its native-first decision, name/role/value, ARIA/DOM states, keyboard matrix, focus path, visual states, and test assertions.
ARIA is not a magic semantic layer for divs; a component is implementable only when native semantics, keyboard behavior, accessible name, state attributes, and visual state agree.96%Frontend Implementationaria / apgARIA APG Widget Pattern Contract
Before hand-rolling complex widgets, extract roles, states, properties, keyboard tables, focus strategy, and test assertions from WAI-ARIA APG; prefer native controls or mature primitives when they fit.
ARIA is a semantic and interaction contract, not magic attributes for divs. Custom comboboxes, dialogs, tabs, treegrids, menus, listboxes, and similar widgets must prove their keyboard, focus, and assistive-technology model first.95%Interaction Responsive Motionkeyboard / navigationKeyboard First Navigation
Keyboard First Navigation turns a frequent interface judgment into an executable constraint before generation.
An interface that works from the keyboard is usually clearer because focus order reveals the real task structure.86%Typography Color Accessibilityfocus / keyboardFocus Order and Reading Order
Focus Order and Reading Order turns a frequent interface judgment into an executable constraint before generation.
A mismatch between visible layout and assistive navigation order breaks orientation and comprehension.86%Typography Color Accessibilityfocus / keyboardVisible Focus States
Keyboard and assistive technology users need to know where focus is; focus states must not be reset away.
Focus state is part of the interaction path, not a browser default flaw.82%