Accessibility Improvements: Screen Reader Announcements for Form Errors

Released in v1.0.431

Overview

As part of our ongoing accessibility programme (control A11Y-10), we have fixed a screen reader gap affecting all major forms in the platform. Error messages that appear after a failed form submission are now correctly announced by screen readers without requiring users to manually navigate to find the error.

What Was the Problem?

When a form submission fails — for example, signing in with incorrect credentials or submitting invalid profile details — the application displays an inline error message. Previously, that error was rendered as a plain <div> element:

<!-- Before: screen readers receive no announcement -->
<div class="rounded-md border border-destructive/30 bg-destructive/10 ...">
  Invalid email or password.
</div>

Because the element had no ARIA live region role, assistive technologies such as NVDA, JAWS, and VoiceOver had no way of knowing that new content had appeared in the DOM. A user relying on a screen reader could submit a form, hear nothing, and have no indication that the submission had failed.

What Changed?

All dynamically-inserted error containers now carry role="alert":

<!-- After: screen readers announce the error immediately -->
<div
  role="alert"
  class="rounded-md border border-destructive/30 bg-destructive/10 ..."
>
  Invalid email or password.
</div>

role="alert" is equivalent to aria-live="assertive" combined with aria-atomic="true". This tells the browser's accessibility tree to:

1. Interrupt any currently-queued speech output.
2. Read the entire error message as an atomic unit as soon as it is inserted.

This is the correct behaviour for form submission errors, where users need immediate, unambiguous feedback.

Affected Forms

Form	File
Sign-in	src/components/auth/credentials-sign-in-form.tsx
Sign-up	src/components/auth/credentials-sign-up-form.tsx
Profile settings	src/components/profile-form.tsx
Organisation settings	src/components/org-settings-form.tsx
Email change	src/components/email-change-form.tsx

The fix has been applied consistently across all five forms so that the accessibility behaviour is uniform throughout the platform.

Who Benefits?

• Screen reader users (NVDA, JAWS, VoiceOver, TalkBack) — errors are announced automatically without manual navigation.
• Users with cognitive or attention-related needs — immediate, assertive announcements reduce the risk of missing critical feedback.
• Keyboard-only users — while role="alert" is primarily a screen reader concern, consistent error surfacing benefits all non-pointer users.

Compliance Context

This change addresses a failure against WCAG 2.1 Success Criterion 4.1.3 — Status Messages (Level AA), which requires that status messages — including errors — be programmatically determinable through role or property so they can be announced by assistive technologies without receiving focus.