Accessibility
Kikita UI treats accessibility as a review process, not a single automated pass. Docs examples should preserve native semantics and expose real component states.
These requirements apply to primitives, docs examples, and consumer verification pages.
| Name | Type | Default | Description |
|---|---|---|---|
| Semantics first | HTML | — | Prefer native elements and browser behavior before adding ARIA. |
| Keyboard | WCAG AA | — | Every interactive state must be reachable, operable, and escapable by keyboard. |
| Focus | Visible state | — | Focus indicators must remain visible and must not cause layout shift. |
| Contrast | WCAG AA | — | Text, icons, focus, disabled, invalid, selected, and loading states must remain distinguishable. |
A clean automated scan is only a smoke test. Do not mark a primitive fully audited without keyboard and assistive-technology review.
| Name | Type | Default | Description |
|---|---|---|---|
| DOM smoke | Automated | — | Catches broken ARIA references, duplicate ids, invalid roles, and unnamed controls. |
| Keyboard review | Manual | — | Verifies tab order, activation keys, escape behavior, and focus restoration. |
| Assistive technology | Manual | — | Uses a real screen reader or platform accessibility tool for names, roles, and states. |
| Visual review | Manual | — | Checks responsive layout, 200% zoom, reduced motion, forced colors, and contrast. |
Examples should use Kikita field wiring and native state attributes instead of compensating for broken markup with custom ARIA.
<kui-field label="Email" hint="Use your work address.">
<input kuiInput type="email" autocomplete="email" />
</kui-field>Record the actual level of review. Be explicit when only DOM smoke has run.
- DOM accessibility smoke has run for <primitive>, but real assistive-technology review is still pending.