Accessibility

Behavior belongs to Atom

Keyboard interaction, focus management, controlled and uncontrolled state, portals, positioning, form integration, and ARIA relationships come from published Atom primitives. Brick does not reproduce them.

Applications still author meaning

Use clear labels, preserve semantic heading order, provide useful alternative text, and connect validation messages to the controls they describe. A component can provide the correct mechanism without inventing your product language.

import { Field, Input } from "@flowstack-ui/brick";

<Field.Root id="work-email" invalid required>
  <Field.Label>Work email</Field.Label>
  <Input name="email" type="email" />
  <Field.Description>Used for account notices.</Field.Description>
  <Field.Error>Enter a valid email address.</Field.Error>
</Field.Root>

Here Brick and Atom connect the control, label, description, required state, and error mechanism. Your application still decides whether the words are accurate and useful.

Inclusive visual requirements

Brick's recipes account for focus-visible, disabled, invalid, selected, forced-color, reduced-motion, narrow, zoomed, touch, pointer, and keyboard states. Consumer overrides inherit responsibility for preserving those distinctions.

Test the complete experience

Start with a practical user path rather than isolated controls:

1. complete the task with only a keyboard;
2. zoom to 200% and repeat it in a narrow viewport;
3. check names, roles, states, errors, and status announcements with assistive technology; and
4. review contrast, motion, touch targets, and Forced Colors.

Automated checks are important, but physical devices, browser chrome, screen readers, touch exploration, content quality, and visual judgment retain explicit human review boundaries.