Validació i missatges d'error

Un formulari que rebutja les dades sense dir quines ni per què és una paret. Qui hi veu bé localitza el camp en vermell; qui fa servir lector de pantalla, qui té baixa visió o daltonisme, o qui simplement va amb pressa, s'encalla. Tres criteris regulen aquest moment: el 3.3.1 Identificació d'errors (A), que exigeix identificar el camp amb error i descriure l'error en text; el 3.3.3 Suggeriments davant d'errors (AA), que demana suggerir la correcció quan es coneix; i el 4.1.3 Missatges d'estat (AA), que exigeix que els missatges que apareixen sense moure el focus siguin anunciats per les tecnologies de suport. Aquesta lliçó tradueix tots tres a codi.

Què ha de tenir un bon missatge d'error

• Text, no només color ni icona. Una vora vermella incompleix el 3.3.1 per si sola i, a més, l'1.4.1 Ús del color.
• Ubicació: al costat del camp, normalment a sota o a sobre, i visible sense desplaçar-se.
• Identificació: quin camp falla («Codi postal») i què passa («ha de tenir 5 xifres»).
• Suggeriment: com arreglar-ho o un exemple vàlid («Exemple: 30001»), sempre que no comprometi la seguretat.
• Associació programàtica amb el camp mitjançant aria-describedby i marcatge de l'estat amb aria-invalid="true".
• Resum al principi del formulari quan hi ha diversos errors, amb enllaços a cada camp.

<label for="cp">Codi postal</label>
<input type="text" id="cp" name="cp" inputmode="numeric"
       autocomplete="postal-code" aria-describedby="cp-ayuda">
<p id="cp-ayuda">5 xifres.</p>
<p id="cp-error" class="error" hidden></p>

<input type="text" id="cp" name="cp" inputmode="numeric"
       autocomplete="postal-code" aria-invalid="true"
       aria-describedby="cp-error cp-ayuda">
<p id="cp-ayuda">5 xifres.</p>
<p id="cp-error" class="error">Error: el codi postal ha de tenir 5 xifres. N'has escrit 4.</p>

Quan validar i on posar el focus

Hi ha dos moments raonables per validar: en sortir del camp (esdeveniment blur) o en enviar el formulari. La validació mentre s'escriu, tecla per tecla, és agressiva: marca com a erroni un correu electrònic incomplet quan la persona encara l'està escrivint, i per a qui fa servir lector de pantalla suposa una interrupció constant. Si valides en sortir del camp, no moguis el focus: només mostra el missatge i marca'l amb aria-invalid.

En enviar el formulari amb errors, l'estratègia més robusta és:

1. Impedir l'enviament.
2. Mostrar un resum d'errors al principi del formulari, dins d'un contenidor amb role="alert" o amb tabindex="-1" al qual es mou el focus.
3. Llistar cada error com un enllaç al camp corresponent, perquè la persona hi pugui anar directament.
4. Marcar cada camp amb aria-invalid="true" i el seu missatge amb aria-describedby.
5. Actualitzar el <title> amb el nombre d'errors.

<div id="resumen-errores" tabindex="-1">
  <h2>Hi ha 2 errors al formulari</h2>
  <ul>
    <li><a href="#cp">Codi postal: ha de tenir 5 xifres</a></li>
    <li><a href="#email">Correu electrònic: hi falta l'arrova</a></li>
  </ul>
</div>

// Després de la validació fallida
const resumen = document.getElementById('resumen-errores');
resumen.hidden = false;
resumen.focus();

Moure el focus al resum és l'opció més clara quan hi ha diversos errors. Com que el lector el llegeix en rebre el focus, no cal afegir-hi també role="alert": combinar totes dues coses pot fer que s'anunciï dues vegades. Si només n'hi ha un, és acceptable moure el focus directament al camp erroni. El que no ha de passar mai és que el formulari es recarregui, el focus torni al principi de la pàgina i la persona hagi de buscar a cegues què ha fallat.

Missatges d'estat i regions actives (4.1.3)

Quan un missatge apareix sense que el focus s'hi mogui (validació en sortir del camp, «Desat correctament», «3 resultats trobats», «Queden 2 intents»), cal assegurar-se que el lector de pantalla l'anunciï. Per això serveixen les regions actives: role="alert" per a errors urgents (interromp el que s'estigui llegint) i role="status" per a confirmacions i missatges informatius (espera que acabi la lectura en curs). Dues regles que fallen constantment: el contenidor ha d'existir al DOM, buit, abans d'inserir-hi el missatge, i no convé tenir més d'una regió activa anunciant alhora.

No dependre només de la validació nativa

L'atribut required i els type específics activen la validació del navegador, que mostra una bombolla al costat del camp. Aquesta bombolla desapareix al cap de pocs segons, no es pot ampliar, no sempre la llegeixen els lectors de pantalla i el seu text no es pot personalitzar en tots els navegadors. Pots aprofitar l'API de validació (checkValidity(), validationMessage) per a la lògica, però mostra els missatges amb el teu propi marcatge. Si fas servir novalidate al <form> per desactivar les bombolles, conserva required: l'estat «obligatori» continua sent programàtic i no cal afegir aria-required.

Prevenció d'errors

El criteri 3.3.4 Prevenció d'errors (legals, financers, de dades) (AA) exigeix que, en operacions amb conseqüències (pagaments, signatura de sol·licituds, esborrament de dades), la persona pugui revisar i corregir abans de confirmar, o que l'operació sigui reversible, o que es comprovi la informació. A la pràctica: una pantalla de resum abans de «Confirma i paga», un botó de «Desfés» després d'esborrar, o la possibilitat d'anul·lar un tràmit durant un termini. I el 3.3.6 Prevenció d'errors (tots) (AAA) ho estén a qualsevol enviament.

Resum

• El 3.3.1 exigeix identificar el camp i descriure l'error en text; el color o la icona sols no són suficients.
• El 3.3.3 demana suggerir la correcció: format esperat, exemple vàlid o valor esperat.
• Associa el missatge amb aria-describedby i marca el camp amb aria-invalid="true".
• Amb diversos errors, mostra un resum enllaçat i mou-hi el focus; evita múltiples regions actives simultànies.
• En operacions amb conseqüències, ofereix revisió, reversió o comprovació (3.3.4).