Dissenyar formularis: etiquetes, ajudes i errors (de 3.3.1 a 3.3.8)

Els formularis són on l'accessibilitat es converteix en un dret efectiu: demanar una cita mèdica, presentar una sol·licitud, comprar, reclamar. També són el lloc on s'acumulen més barreres: etiquetes que desapareixen, errors que només s'indiquen en vermell, camps que demanen la mateixa dada tres vegades, contrasenyes impossibles. Aquesta lliçó recorre els criteris de la pauta 3.3 «Ajuda a l'entrada de dades» des del punt de vista del disseny, inclosos els dos criteris nous de WCAG 2.2.

Etiquetes i instruccions (3.3.2)

El criteri 3.3.2 Etiquetes o instruccions (A) exigeix que es proporcionin etiquetes o instruccions quan el contingut requereix l'entrada de dades. Decisions de disseny:

• Etiqueta visible, sempre, a sobre o a l'esquerra del camp. El placeholder no és una etiqueta: desapareix en escriure, sol tenir un contrast insuficient i no el llegeixen de manera fiable totes les tecnologies de suport. Els dissenys «flotants» (l'etiqueta puja en escriure) són acceptables si l'etiqueta continua visible i llegible en tot moment.
• Instruccions abans del camp, no després: format esperat («DD/MM/AAAA»), requisits («mínim 8 caràcters»), exemples. Si van després, qui fa servir lector de pantalla les descobreix tard.
• Camps obligatoris indicats amb text o amb un asterisc explicat al començament del formulari. Si gairebé tots són obligatoris, marca els opcionals.
• Agrupa els camps relacionats (adreça, dates, opcions d'un mateix tema) amb un títol de grup visible, que en codi serà fieldset i legend.
• Una columna. Diverses columnes es llegeixen en un ordre confús amb el zoom i el lector de pantalla.

Errors: detectar-los, descriure'ls, suggerir (3.3.1, 3.3.3)

El criteri 3.3.1 Identificació d'errors (A) exigeix que, si es detecta automàticament un error, l'element erroni s'identifiqui i l'error es descrigui en text. El criteri 3.3.3 Suggeriments davant d'errors (AA) afegeix que, si se sap com corregir-lo, se suggereixi la correcció (tret que comprometi la seguretat o el propòsit). Patró de disseny recomanat:

1. Resum d'errors al començament del formulari després d'enviar-lo, amb el focus desplaçat cap al resum, i amb cada error enllaçat al seu camp.
2. Missatge al costat del camp, en text, amb icona, no només amb color (1.4.1). En codi es vincularà amb aria-describedby i aria-invalid.
3. Text que explica què està malament i com arreglar-ho: «Escriu la data amb el format DD/MM/AAAA, per exemple 05/03/1990», no «Camp no vàlid».
4. Conservar les dades introduïdes: no buidar mai el formulari després d'un error.
5. Validació en el moment adequat: en sortir del camp o en enviar; mai amb cada tecla premuda, que genera errors abans d'acabar d'escriure.

<!-- Missatge d'error correcte: visible, en text, vinculat al camp -->
<label for="email">Correu electrònic (obligatori)</label>
<input id="email" type="email" autocomplete="email"
       aria-describedby="email-error" aria-invalid="true">
<p id="email-error">Error: falta el símbol @. Exemple: nom@domini.cat</p>

Prevenir errors greus (3.3.4)

El criteri 3.3.4 Prevenció d'errors (legals, financers, dades) (AA) exigeix que, en transaccions amb conseqüències legals o econòmiques o que modifiquin dades de l'usuari, es compleixi almenys una de tres condicions: l'acció és reversible, les dades es comproven i es dona l'oportunitat de corregir-les, o hi ha un pas de confirmació abans de finalitzar. En disseny: una pantalla de revisió abans de pagar o signar, amb possibilitat de tornar a cada pas, i confirmacions explícites per esborrar dades.

Novetats de WCAG 2.2

3.3.7 Entrada redundant (A)

La informació que la persona ja ha introduït en un procés no s'ha de tornar a demanar: s'emplena automàticament o s'ofereix per seleccionar-la («Fes servir la mateixa adreça per a l'enviament»). Excepcions: quan tornar-la a introduir és essencial (per exemple, en un joc de memòria), quan ho exigeix la seguretat (confirmar una contrasenya nova que no es mostra a la pantalla o tornar a escriure l'actual) o quan la dada anterior ja no és vàlida. Beneficia persones amb dificultats de memòria, d'atenció o de mobilitat, per a les quals repetir dades és un cost real.

3.3.8 Autenticació accessible (mínim) (AA)

Cap pas d'un procés d'autenticació no pot exigir una prova de funció cognitiva (recordar una contrasenya, transcriure caràcters, resoldre un trencaclosques, fer un càlcul) tret que es compleixi almenys una condició: hi ha un mètode alternatiu sense prova cognitiva; hi ha un mecanisme d'ajuda (per exemple, permetre enganxar la contrasenya o fer servir un gestor de contrasenyes); la prova consisteix a reconèixer objectes; o la prova consisteix a reconèixer contingut no textual proporcionat per la mateixa persona (la seva foto). Conseqüències pràctiques de disseny:

• No bloquejar mai l'enganxament als camps de contrasenya ni els gestors de contrasenyes.
• Oferir l'inici de sessió amb un enllaç màgic per correu, biometria del dispositiu, passkeys o codis d'un sol ús que es puguin copiar i enganxar.
• Si hi ha CAPTCHA, que no sigui de transcripció, o que hi hagi una alternativa.
• Els codis per SMS són una prova cognitiva tret que es puguin enganxar o s'emplenin automàticament.

El criteri 3.3.9 (AAA) elimina les excepcions de reconeixement d'objectes i de contingut propi.

Relacionat: el criteri 1.3.5 Identificar el propòsit de l'entrada (AA) exigeix que els camps de dades personals habituals (nom, correu, telèfon, adreça) en declarin el propòsit, a la pràctica amb l'atribut autocomplete; documenta en el disseny quina dada recull cada camp.

Resum

• 3.3.2 Etiquetes o instruccions (A): etiquetes visibles i permanents, instruccions abans del camp, obligatoris indicats, una columna.
• 3.3.1 Identificació d'errors (A) i 3.3.3 Suggeriments davant d'errors (AA): resum d'errors, missatge en text al costat del camp, com corregir-lo, sense buidar les dades.
• 3.3.4 Prevenció d'errors (AA): reversible, comprovat o confirmat en transaccions legals, financeres o de dades.
• 3.3.7 Entrada redundant (A, nou): no demanar dues vegades el que ja s'ha introduït en el mateix procés.
• 3.3.8 Autenticació accessible (mínim) (AA, nou): sense proves cognitives obligatòries; permetre enganxar, gestors de contrasenyes, passkeys o alternatives. 1.3.5: camps amb autocomplete.