Forms and accessibility

Native forms

• Controls are form-associated: they submit their name and value, reset with the form, and follow a disabled <fieldset>.
• Validation uses the constraint API (required, checkValidity(), validity); errors show after the user leaves a field or submits, with the :state(user-invalid) custom state.
• <odd-validation-summary> lists a form’s problems after a submission that validation blocked, takes focus, and links each problem to its control.

<form>
  <odd-input name="email" type="email" label="Email" required></odd-input>
  <odd-checkbox name="terms" required>I accept the terms</odd-checkbox>
  <odd-button type="submit" appearance="primary">Create account</odd-button>
</form>

Accessibility

• Each element names its pattern and keyboard model in its reference (a11y and keyboard in the metadata).
• Focus rings are outlines that stay visible in forced-colours mode (checked with forced-colours emulation in three engines); colour never carries meaning alone.
• Targets never fall below the target-size token; text wraps inside narrow containers.
• Motion follows prefers-reduced-motion.

Evidence:

• Browser and e2e tests drive the elements by keyboard (Tab order, arrow keys, Enter, Escape) in Chromium, Firefox, and WebKit.
• axe-core (WCAG 2.2 A and AA rules) audits the button, input, badge, card, and display elements in light and dark mode, and the example pages: components-only, forms, presentation, the AI demos, and Workbench.

Limitations: screen readers are not yet verified, and no conformance level is claimed.

The support policy lists this evidence with the rest of what Oddkin is tested with.