Quan els teus missatges d'error exclouen usuaris

El moment en què el formulari es trenca

Imagina’t això: una usuària cega omple un formulari de pagament, l’envia i el seu lector de pantalla no li diu res d’útil. Cap anunci. Cap explicació. La pàgina ha marcat visualment cinc errors de validació en vermell, però la usuària no en té ni idea. Torna a prémer enviar. I una altra vegada. Al final, marxa.

No és un escenari marginal. La gestió inaccessible dels errors és una de les barreres més comunes que trobem en auditories reals, i és una de les que tendeix a frustrar els usuaris en el pitjor moment possible: quan intenten completar una transacció o enviar alguna cosa important.

La bona notícia és que solucionar-ho és sobretot una qüestió de saber com és el “bé fet”. Els errors són gairebé sempre els mateixos pocs patrons.

Per què els missatges d’error són difícils per als usuaris de tecnologies d’assistència

Els usuaris vidents que fan servir el ratolí solen notar els errors de validació immediatament: la vora vermella, la icona d’advertència, el text que apareix sota el camp. Però els usuaris que depenen de lectors de pantalla, de la navegació amb teclat o del control per veu s’enfronten a una experiència fonamentalment diferent.

Quan s’envia un formulari i apareixen errors:

Els usuaris de lectors de pantalla poden no sentir res tret que el focus es mogui a l’error o que una regió activa l’anunciï
Els usuaris de teclat han de poder arribar a cada missatge d’error des del teclat i entendre a quin camp pertany
Els usuaris de control per veu han de poder referir-se als camps mitjançant una etiqueta visible i precisa — si l’etiqueta és incorrecta o no existeix, es queden encallats

Res d’això passa automàticament. Ho has de construir.

Els criteris de les WCAG que s’apliquen

Quatre criteris d’èxit de les WCAG 2.2 cobreixen directament la gestió d’errors:

3.3.1 Identificació d’errors (nivell A) — Si es detecta un error automàticament, l’element erroni s’ha d’identificar i descriure a l’usuari en text. No pots transmetre els errors només mitjançant el color.

3.3.2 Etiquetes o instruccions (nivell A) — Els camps que requereixen un format específic han de deixar clar aquest requisit abans o durant la introducció de dades, no només després que falli l’enviament.

3.3.3 Suggeriment davant els errors (nivell AA) — Si es detecta un error i es coneixen suggeriments per corregir-lo, cal proporcionar-los. “Data no vàlida” no és suficient. “Introdueix la data en format DD/MM/AAAA” sí que ho és.

3.3.4 Prevenció d’errors (nivell AA) — Per a enviaments amb conseqüències importants (transaccions financeres, acords legals), dóna als usuaris la possibilitat de revisar, corregir i confirmar abans que l’acció sigui permanent.

També hi ha el criteri 4.1.3 Missatges d’estat (nivell AA), que cobreix els missatges injectats dinàmicament que no reben el focus: aquests han de ser anunciats per les tecnologies d’assistència mitjançant role="status" o role="alert".

Què necessita realment un missatge d’error accessible

Fer bé els missatges d’error requereix parar atenció a quatre capes diferents:

1. La connexió programàtica

Cada missatge d’error ha d’estar vinculat al seu camp mitjançant aria-describedby. Això indica als lectors de pantalla que anunciïn el text de l’error quan el camp rep el focus.

<!-- Before: error text exists visually but is invisible to screen readers -->
<label for="email">Email</label>
<input type="email" id="email" class="error">
<p class="error-text">Enter a valid email address.</p>

<!-- After: programmatic association via aria-describedby -->
<label for="email">Email address</label>
<input
  type="email"
  id="email"
  aria-describedby="email-err"
  aria-invalid="true"
>
<p id="email-err" class="error-text">Enter a valid email address.</p>

L’atribut aria-invalid="true" indica que el camp és actualment invàlid, cosa que la majoria de lectors de pantalla anuncien quan el focus hi arriba.

2. Gestió del focus després de l’enviament

Quan s’envia un formulari i hi ha errors, el focus s’ha de moure a un lloc útil. Els dos patrons més comuns:

Moure el focus a un resum d’errors a la part superior del formulari que llisti tots els errors amb enllaços als camps corresponents
Moure el focus al primer camp amb error

Si el focus es queda al botó d’enviament o enlloc, els usuaris de lectors de pantalla han de descobrir els errors pel seu compte navegant pel formulari — si és que arriben a saber que existeixen.

// After validation fails, move focus to the error summary
const summary = document.getElementById('error-summary');
summary.setAttribute('tabindex', '-1');
summary.focus();

3. Anuncis amb regions actives per a errors dinàmics

Per als errors que apareixen mentre l’usuari escriu (validació en línia en temps real), utilitza regions actives ARIA perquè el missatge s’anunciï sense que calgui moure el focus.

<p role="alert" aria-live="assertive" id="password-err">
  Password must be at least 8 characters.
</p>

Utilitza role="alert" / aria-live="assertive" per a errors que requereixen atenció immediata. Utilitza role="status" / aria-live="polite" per a comentaris menys urgents que poden esperar que l’usuari faci una pausa.

4. El missatge d’error en si

El llenguatge importa. Els missatges d’error accessibles són:

Específics: diuen què està malament, no només que alguna cosa està malament
Accionables: diuen a l’usuari exactament què ha de fer per solucionar-ho
Educats: eviten llenguatge culpabilitzador com “has introduït un valor no vàlid”

Inaccessible	Accessible
”Entrada no vàlida"	"L’adreça electrònica ha d’incloure un símbol @, p. ex. nom@exemple.com"
"Error"	"La data ha de tenir el format DD/MM/AAAA"
"Camp obligatori"	"El nom complet és obligatori"
"Contrasenya no vàlida"	"La contrasenya ha de tenir com a mínim 8 caràcters i incloure un número”

Patrons per a diferents escenaris d’error

Errors en línia al camp

El patró més comú. Un missatge d’error apareix directament sota el camp associat. Funciona bé per a formularis simples. Requereix aria-describedby i aria-invalid perquè s’anunciï correctament.

Bàners de resum d’errors

Per a formularis llargs amb diversos errors, col·loca un resum a la part superior que llisti tots els problemes com a enllaços que salten al camp corresponent. Mou-hi el focus després d’un enviament fallit. És el patró que utilitza GOV.UK i el que es recomana àmpliament per a formularis complexos.

Notificacions toast

Els missatges de curta durada que apareixen a la vora de la pantalla són un dels patrons més inaccessibles d’ús comú. Desapareixen abans que els usuaris de lectors de pantalla hi puguin arribar, sovint no s’anuncien en absolut i no ofereixen cap via de recuperació. Evita utilitzar toasts per als errors. Si els fas servir, acompanya’ls d’un estat d’error persistent al mateix formulari.

Errors del sistema

Quan alguna cosa falla al servidor, explica a l’usuari amb llenguatge planer què ha passat i què pot fer a continuació. “Alguna cosa ha anat malament” sense més indicacions deixa els usuaris abandonats.

<div role="alert" aria-live="assertive">
  <p>We couldn't save your changes due to a network error.
  Please check your connection and try again.</p>
</div>

La llista de comprovació de proves

Després d’implementar la gestió d’errors, verifica manualment aquests punts — les eines automàtiques no en detectaran la majoria:

En enviar un formulari obligatori buit, el focus es mou a un resum d’errors o al primer camp amb error
Cada missatge d’error està vinculat al seu camp mitjançant aria-describedby
Els camps amb error tenen aria-invalid="true"
Els missatges d’error s’anuncien quan el focus arriba al camp afectat
La validació en temps real utilitza regions actives
Els missatges d’error utilitzen un llenguatge específic i accionable — no només “no vàlid”
El color no és l’única manera d’indicar els errors (una icona o una etiqueta de text al costat del vermell)
Es pot arribar a l’error amb el tabulador des del teclat
L’ordre del focus després de l’enviament és lògic i no salta de manera imprevisible
Els missatges toast van acompanyats d’un estat d’error persistent

Per què les eines automàtiques no detecten la major part d’això

Un escàner automàtic pot comprovar si aria-describedby apunta a un element existent i si aria-invalid hi és present. No pot comprovar si el focus es mou correctament després de l’enviament, si el text de l’error és precís o si una notificació toast desapareix abans que es pugui llegir. Les nostres auditories manuals d’accessibilitat inclouen proves específiques de formularis amb tecnologies d’assistència reals — l’única manera fiable de verificar que la gestió d’errors realment funciona de principi a fi.

Si no saps en quin punt es troben els teus formularis, fes una anàlisi gratuïta per detectar primer els problemes automatitzables, i a partir d’aquí continua.