Accessibility
Status, validation and announcements
Make local simulation, pending work and real acknowledgement distinguishable.
On this page
Feedback findings
| UI | Current behavior | Required distinction |
|---|---|---|
| AI failure | role=alert message | A draft failed; no message was sent. |
| Draft saved | Timer after 500ms | Local fingerprint only, not persistence. |
| Toast | 3200ms message in app | role=status is present; duration and assistive-technology announcement still need review. |
| Delivery failure | Persistent banner + Retry | Retry changes local status only. |
| Settings save | Close + toast | Some callbacks do not mutate records at all. |
| Email form validation | Presence checks / simple regex | Invalid/duplicate/suppressed recipients need server validation. |
Guidance for implementation
- Keep failure explanation near the task and preserve draft content.
- Use aria-live/status for background acknowledgements when appropriate, without announcing every keystroke.
- Associate field errors with controls using aria-describedby and aria-invalid.
- Keep a durable history for consequential send, merge and permission changes.
- Avoid claiming success before provider/server confirmation.
Source references
| File | Responsibility |
|---|---|
| components/helpdesk-app.tsx | Transient toast |
| components/inbox/composer.tsx | Draft/error states |
| components/views/settings-editors.tsx | Save callbacks |
Examples from the app
Actual Sonarist components with fictional conversations, people, example.com addresses and simulated operational states. Captured at 2× resolution or higher. Select an image to inspect it full size.
Related topics
Source audit: 2026-10-08 · Revision 10f45d1377b5 · Documentation v1.0.0