Accessibility

Make each task work with a keyboard, assistive technology, and enlarged text. Use the shared components as a starting point, then test the complete screen: labels, content, layout, and custom behavior affect accessibility.

Use WCAG 2.2 Level AA as a review target. The checks here are a starting point for that review; passing them alone does not establish conformance.

Contrast

Measure the rendered foreground against its actual background in both light and dark themes.

Start with fg.body or fg.heading for required text. Verify fg.muted and fg.subtle before using them for small labels or descriptions. Disabled controls and decorative graphics have exceptions in the criteria; a status message or help text still needs to be readable.

Use the matching palette's fg.onSolid on solid fills. Provide a text label or another visual cue for errors, selected states, and status so color carries only part of the meaning.

Keyboard and focus

• Use native links for navigation and buttons for actions. Keep every task available from the keyboard, including alternatives to drag-only interactions.
• Follow the interaction documented for each component: Tab moves between controls, while composite controls may use arrow keys within them.
• Keep a visible focus indicator and make sure sticky headers, footers, and overlays do not cover the focused control.
• When opening a dialog, move focus into it. On close, return focus to its trigger or a sensible next control if the trigger has been removed.
• Preserve the component's focus handling when adding wrappers or custom event handlers.

Try the complete flow using Tab, Shift+Tab, Enter, Space, arrow keys, and Escape where appropriate. See WCAG keyboard guidance, Dialog, and Menu.

Names, forms, and updates

Give every control an accessible name. An icon-only action needs a name such as “Delete filter”; a tooltip is useful supporting text, but check the control's accessible name directly. Hide decorative icons from assistive technology.

Associate visible labels with inputs. Keep instructions available while a person types, and connect error text to the affected control. Describe how to fix the value. The Form documentation covers composing labels, fields, and validation messages.

Announce asynchronous results when people need to know that an action succeeded or failed. Use an appropriate live region without moving focus for routine updates, and avoid repeating announcements while nothing meaningful changes.

Layout, targets, and motion

Pointer targets should be at least 24 × 24 CSS pixels or meet one of the target-size exceptions, such as sufficient spacing. For touch-heavy screens, aim for larger targets, such as 44 × 44 CSS pixels, where the layout permits.

Check reflow at 320 CSS pixels. Keep two-dimensional content, such as data tables and graphs, in a contained region so surrounding prose and controls can reflow.

Honor reduced-motion preferences for custom transitions and illustrations. See Motion for a starting implementation.

Review a complete task

Run an automated accessibility check, then complete a task manually with a keyboard and a screen reader. Repeat with zoom, narrow layouts, both themes, reduced motion, and error states. Record issues against the screen and interaction where they occur, including the browser and assistive technology used.