Accessibility
Build inclusive interfaces by default with semantic markup, keyboard support, and clear validation behavior.
How To Use This Page
Follow this three-step flow when reviewing accessibility for a new screen or release candidate.
Foundations
Confirm WCAG AA targets and interaction contracts.
Patterns
Review interaction and screen reader contracts before implementation.
Test Checklist
Run manual checks before release and attach results to QA.
WCAG AA Target
Kalki Design targets WCAG 2.1 Level AA across all components and interaction patterns.
Perceivable
Text contrast, non-color indicators, and readable content hierarchy.
- ✓Contrast ratio meets WCAG AA
- ✓State is not conveyed by color only
Operable
Full keyboard support and visible focus across all controls.
- ✓Tab order is logical
- ✓Focus ring is always visible
Understandable
Clear labels, instructions, and error recovery messages.
- ✓Fields have labels
- ✓Errors are specific and actionable
Robust
Semantic HTML and ARIA patterns compatible with assistive tech.
- ✓Proper input semantics
- ✓ARIA attributes wired correctly
Keyboard Interaction Contract
Every interactive component must be fully operable via keyboard alone.
| Element | Key | Expected Behavior |
|---|---|---|
| Text input / textarea | Tab / Shift+Tab | Moves focus in and out in logical order. |
| Checkbox / radio | Space | Toggles selected state while focus remains visible. |
| Select / menu trigger | Enter / Space | Opens list; arrow keys navigate options. |
| Dialog | Esc | Closes dialog and returns focus to trigger. |
| Form submit with errors | Enter | Shows summary + inline errors and focuses first invalid field. |
Accessible Form Pattern
On submit failures, show a form-level summary plus inline field messages.
There is a problem
Enter an email address in the correct format
Use your legal name as on ID.
Include what happened and when it started.
Accept terms to continue
Screen Reader Contract
- Field labelsEvery form control has a visible label linked via `htmlFor`/`id`.
- Described byHelper and error text are connected with `aria-describedby`.
- Invalid stateInvalid controls set `aria-invalid="true"` when validation fails.
- Error summary regionForm-level error summary uses alert semantics for announcement.
Manual Test Checklist
Run these checks in product context, not only in isolation.
- 01Tab through the entire page and confirm visible focus on every interactive element.
- 02Verify labels and helper/error text are announced by a screen reader.
- 03Submit with invalid form values and verify summary + inline errors both appear.
- 04Check contrast in light and dark mode for text, borders, and focus rings.
- 05Zoom to 200% and verify layout remains usable without hidden critical content.
- 06Disable pointer input and confirm keyboard-only completion of critical flows.
WCAG Testing Example
Example manual test pass for a form flow. Use this structure in QA tickets and release checks.
| WCAG Criterion | Scenario | How To Test | Pass | Fail |
|---|---|---|---|---|
| 1.4.3 Contrast (Minimum) | Body text on card surface | Check contrast ratio for text vs background in light and dark. | Ratio is >= 4.5:1 for normal text. | Muted text drops below 4.5:1. |
| 2.4.7 Focus Visible | Tab through input and checkbox fields | Use keyboard only and verify a visible focus indicator always appears. | Ring/border clearly visible on every focusable element. | Focus style removed or too subtle to detect. |
| 3.3.1 Error Identification | Submit form with invalid email and unchecked terms | Trigger validation and inspect inline + summary feedback. | Summary + inline text errors appear with `aria-invalid`. | Only red border shown, no message. |
| 3.3.2 Labels or Instructions | Review all form controls | Ensure each field has a visible label and clear instruction when needed. | Label and helper text are programmatically associated. | Placeholder-only field without label. |
Testing Workflow
1. Keyboard pass
Navigate every control with Tab, Shift+Tab, Enter, Space, and Esc.
2. Screen reader spot-check
Verify labels, helper text, and error announcements are spoken correctly.
3. Contrast checks
Validate text and state pair contrast in both light and dark themes.
4. Regression coverage
Keep automated checks and visual snapshots for core flows.
Common Failures
Common Problems
- Missing visible labels or relying on placeholder text only.
- Removing focus styles for visual polish.
- Using color as the only state indicator.
- Showing generic errors without recovery guidance.
Preferred Outcome
- Every control has clear labels and helper/error mapping.
- Keyboard-only users can complete full flows.
- Errors are visible inline and in summary on submit.
- All states remain readable in both light and dark themes.