WCAG 2.1 Level AA is the baseline we adhere to. It's the standard referenced throughout this design system, and any new pattern should be designed to meet it before it ships.

Accessibility needs are common, not edge cases. Roughly one in six people has a disability that affects how they use software, and everyone moves in and out of situational limitations - a broken arm, bright sunlight, a slow network, a noisy room. Designing well for the following groups makes the product better for everyone:

Visual: low vision, color blindness, blindness. Relies on contrast, text resizing, and screen reader support rather than color or icon shape alone.
Motor: limited fine motor control, tremor, or reliance on a keyboard, switch, or voice control rather than a mouse or touch. Relies on generous target sizes, full keyboard operability, and forgiving interaction timing.
Auditory: deafness or hearing loss. Relies on captions, transcripts, and visual equivalents for anything communicated by sound.
Cognitive: attention, memory, or processing differences; also includes anyone unfamiliar with the product or under time pressure. Relies on clear language, consistent patterns, and forgiving error recovery.
Situational: a temporary or context-driven limitation: one-handed use, a cracked screen, glare, a slow connection. Relies on the same accommodations as the permanent version of that limitation.

Design for the person with the constraint, not the average case, and the pattern holds up for everyone else too.

Color Contrast

Color is a communication tool, not decoration. It should reinforce meaning, never carry it alone.

The baseline is WCAG 1.4.3: 4.5:1 contrast for normal text, 3:1 for large text and UI components.
Focus indicators must meet 3:1 contrast against their background. Disabled states are the only legitimate exemption from contrast requirements. If a state is interactive, it must meet contrast.
Semantic status colors (success / error / warning / info) need strict AA contrast across every theme and surface, not just the default.
Balance brand expression against accessibility. A brand color that fails contrast needs a darker or lighter accessible variant, not an exception.

Focus Indicators

Modals and dialogs: on open, focus moves to the first interactive element or the dialog heading.
Data tables: prefer row-level focus over cell-level focus. Focusing the row rather than each individual cell reduces cognitive overhead for keyboard and screen reader users.
Menus and dropdowns: when a menu opens, the first item receives focus immediately.
Carousels and sliders: each slide or item must be independently focusable, with the focus ring rendered on the active item.
Toast notifications: if a toast contains interactive actions (Dismiss, Undo), those actions must be keyboard-focusable. A toast that disappears before it can be reached defeats the purpose.

Keyboard Support

Every interactive pattern needs a complete keyboard story before it's considered done. These conventions should hold everywhere in the product:

Key	Behavior
Tab	Sequential navigation - moves forward through focusable elements in DOM order.
Arrow Keys	Navigate within a composite widget once focus is inside it (e.g., between options in a picklist, days in a calendar).
Escape	Dismiss / exit - closes menus, dialogs, and popovers, and returns focus to the trigger that opened them.
Enter/Space	Activate - Enter activates links and buttons; Space activates checkboxes, radios, and toggles. In menus and selects, Enter selects and Space toggles.
Home/End	Jump to the first or last item in a list, grid row, or toolbar.
Type ahead	Pressing a letter key while a picklist, menu, or tree is open jumps to the first matching item.

Touch target sizing

Enterprise practice generally clusters around two tiers: a ~40–44px tier and a ~48px tier for primary actions. Across both, 24×24px is the non-negotiable floor, matching the WCAG 2.2 minimum.

Separate a component's visual size from its hit area. An icon or affordance can be shrunk visually without shrinking what's actually tappable.
Treat spacing between adjacent targets as a companion rule. Leave at least 8px between adjacent interactive elements, even when each one individually clears the minimum size.

Interactive states

Every interactive component splits its states into two families, and specs should name that split explicitly:

Transient states: hover, focus, pressed. These clear automatically once the interaction ends.
Persistent states: selected, disabled. These hold until the underlying data changes.

Motion and animation

Enter and exit transitions are never symmetrical. Everything should decelerate in and accelerate out.
Design motion in at least two tiers: micro/interaction motion (a button press, a toggle flip) and macro/transition motion (a panel sliding in, a page transitioning). This makes it so they feel like one system at different scales, not unrelated effects.
Linear easing is reserved strictly for mechanical motion like spinners, progress bars etc. Never use it for anything meant to feel natural or human.

Typography and readability

Build type scales on a fixed ratio (roughly 1.125–1.2×) stepped up from a base size and rounded for grid alignment. Scales should not ad hoc sizes per component.
12px is the floor. Below that, text becomes an accessibility problem regardless of contrast or weight.
Line height should be tighter for headings (~1.2–1.3×) and looser for body copy (~1.4–1.7×).
Use relative units (rem, sp, or t-shirt sizes) rather than fixed pixel values, so OS and browser-level zoom and font-size settings are respected.
For hierarchy in dense UI, reach for weight before size. it's a subtler signal that doesn't force the layout to accommodate larger text.

Additional Reading

Web Content Accessibility Guidelines (WCAG) guidelines https://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-contrast.html
Writing for Web Accessibility https://www.w3.org/WAI/tips/writing/

Overview

Animation