Accessibility checklist
Medi-Chi is built so that keyboard-only users, screen-reader users, and low-vision users can complete the full diagnose-guide workflow without the mouse. This page documents exactly what happens at each interaction so assistive-technology users know what to expect — and so we can be held to it.
Form error handling
The contact form, login form, and symptom questionnaire all share the same error-summary contract. The summary uses role="alert" so it is announced once on insertion, and never re-announces stale content.
| When you… | The app… |
|---|---|
| Submit a form with invalid fields | An assertive error summary appears at the top of the form. Screen readers announce the aggregated error list once. |
| Activate a link inside the error summary (Enter or click) | Focus jumps to the matching field. The element you were last working on is remembered for restoration. |
| Press Escape anywhere inside the form | The summary is dismissed and focus returns to the field you were last working on (or the first form input as a fallback). |
| Press Enter or Space on the dismiss (X) button | The summary is dismissed and focus restores into the form — never to document.body or the destroyed button. |
| Resubmit the form without changing any field | The assertive summary stays dismissed (no re-announce). The destructive toast and inline field error still update so sighted users see the rejection. |
| Resubmit with a different error set, or re-trigger the same error after a successful send | The assertive summary re-mounts and is announced again. Suppression is one-shot, never permanent. |
| Multiple assertive regions in the document | Exactly one region carries the aggregated 'Please fix the following…' copy at any moment. Per-field inline alerts stay scoped to their field. |
Diagnose-guide workflow
The 12-step symptom questionnaire and AI diagnosis are designed so that focus and announcements stay predictable across loading states.
| When you… | The app… |
|---|---|
| Navigate the symptom questionnaire by keyboard | Every step is reachable via Tab. Single-select uses radio semantics; multi-select uses checkbox semantics with explicit labels. |
| Submit a step with required fields missing | Inline field errors appear with role='alert' so screen readers hear them immediately. Focus is moved to the first invalid field. |
| AI diagnosis is generating | A polite live region announces progress (e.g. 'Analysing pattern…') without interrupting any current screen-reader speech. |
| Diagnosis result loads | The result heading receives focus so screen readers start reading the diagnosis from the top, not from a stale spinner. |
| Open the patient export / PDF preview dialog | Focus is trapped in the dialog. Escape closes it and returns focus to the trigger button. |
General visual and motion
| When you… | The app… |
|---|---|
| Color contrast | All text and interactive controls meet WCAG AA (4.5:1 for body text, 3:1 for large text and non-text indicators). |
| Visible focus | Every focusable element shows a 2px ring in the destructive or primary color — never relies on color alone. |
| Skip / fallback focus | Destroyed elements (dismiss buttons, closed dialogs) never leave focus on document.body. Focus always restores to a sensible form control. |
| Reduced motion | Smooth scrolls used for focus restoration honor prefers-reduced-motion via the browser default; no parallax or auto-playing motion in critical flows. |
Live focus-restoration announcer
The polite live region below announces, in real time, where keyboard / screen-reader focus is restored after dismissing an assertive error summary anywhere in the app (contact form, login, diagnose-guide flow). Screen readers queue each announcement after their current speech, so it never competes with the dismissed assertive alert. The visible transcript mirrors the live region for sighted auditors.
Reporting an accessibility issue
If a keyboard or screen-reader interaction does not match what is documented here, that is a bug.
Please report it via the contact form with the screen reader, browser, and step that triggered it — we triage accessibility regressions ahead of feature work.