Ajuda a l'entrada de dades: 3.3.1 a 3.3.4, 3.3.7 Entrada redundant i 3.3.8 Autenticació accessible

Els formularis són el lloc on el web deixa de ser lectura i es converteix en gestió: presentar una sol·licitud, pagar, reservar, identificar-se. La pauta 3.3 (ajuda a l'entrada de dades) estableix com s'han de prevenir i gestionar els errors i, des de les WCAG 2.2, com evitar exigències innecessàries de memòria i repetició. Aquesta lliçó recorre els criteris A i AA de la pauta amb el detall que exigeix una auditoria de processos complets.

3.3.1 Identificació d'errors (A)

Si es detecta automàticament un error d'entrada, s'identifica l'element erroni i es descriu l'error a l'usuari en text. Dues condicions: assenyalar quin camp falla i explicar què passa. Com avaluar-lo: envia el formulari buit, amb formats incorrectes i amb valors fora de rang; comprova que el missatge sigui textual, visible i associat programàticament al camp (aria-describedby) o inclòs a la seva etiqueta; que el lector l'anunciï (focus mogut al primer error, resum amb role="alert" o enllaços als camps); que aria-invalid="true" marqui el camp. Fallades: vora vermella sense text (també 1.4.1); missatge genèric «hi ha errors al formulari» sense indicar quins; missatge que apareix lluny del camp i no s'anuncia; errors mostrats només amb una icona; missatge que desapareix al cap de pocs segons.

3.3.2 Etiquetes o instruccions (A)

Quan el contingut requereix una entrada de l'usuari, es proporcionen etiquetes o instruccions. El criteri exigeix que existeixin i siguin visibles (l'associació programàtica l'exigeixen l'1.3.1 i el 4.1.2): un camp l'únic text del qual és el placeholder incompleix el 3.3.2, perquè la instrucció desapareix en escriure. També cobreix els formats requerits («dd/mm/aaaa»), els camps obligatoris (indicats de manera comprensible, no només amb un asterisc sense explicació) i els grups d'opcions amb la seva pregunta visible. Fallades: placeholders com a etiqueta; icones sense text; instruccions de format que apareixen només després de l'error; etiquetes visuals separades del seu camp.

3.3.3 Suggeriments davant d'errors (AA)

Si es detecta un error i es coneixen suggeriments per corregir-lo, s'ofereixen, tret que comprometin la seguretat o el propòsit. «Camp incorrecte» no compleix; «Introduïu el DNI amb vuit xifres i lletra, per exemple 12345678A» sí que compleix. En contrasenyes incorrectes no cal dir quina part falla (seguretat). Avaluació: provoca errors concrets (data impossible, correu sense arrova, codi postal de quatre dígits) i comprova que el missatge indiqui com corregir-los.

3.3.4 Prevenció d'errors (legals, financers, dades) (AA)

Per a pàgines que generen compromisos legals o transaccions financeres, modifiquen o esborren dades controlables per l'usuari, o envien respostes d'examen, s'ha de complir almenys una de tres condicions: l'acció és reversible; les dades es comproven i l'usuari les pot corregir; o hi ha un mecanisme de revisió i confirmació abans de finalitzar. On s'aplica: pagament, signatura i presentació de sol·licituds en una seu electrònica, baixa de serveis, esborrament del compte, enviament de reclamacions. Fallades: botó «Presenta» que registra la sol·licitud sense pantalla de resum ni possibilitat d'anul·lació; compra en un clic sense confirmació ni cancel·lació.

<label for="dni">DNI <span>(obligatori, vuit xifres i lletra)</span></label>
<input id="dni" name="dni" required aria-required="true"
       aria-invalid="true" aria-describedby="dni-error"
       autocomplete="off" inputmode="text">
<p id="dni-error" class="error">
  Error: el DNI ha de tenir vuit xifres seguides d'una lletra, per exemple 12345678A.
</p>

3.3.7 Entrada redundant (A) — nou a la 2.2

La informació que l'usuari ja ha introduït o que se li ha proporcionat en el mateix procés s'ha d'emplenar automàticament o ha d'estar disponible per seleccionar-la, tret que tornar-la a introduir sigui essencial (per exemple, en un joc de memòria), sigui necessari per garantir la seguretat del contingut, o la informació anterior ja no sigui vàlida. El cas típic: adreça d'enviament i de facturació («fes servir la mateixa adreça» amb una casella), dades personals demanades al pas 1 i un altre cop al pas 4, correu electrònic repetit en pantalles successives. Avaluació: recorre cada procés anotant quines dades es demanen més d'una vegada i si hi ha emplenament automàtic o selecció; recorda que es refereix al mateix procés (una sessió), no a visites diferents.

3.3.8 Autenticació accessible (mínim) (AA) — nou a la 2.2

Cap pas d'un procés d'autenticació no pot exigir una prova de funció cognitiva (recordar una contrasenya o un codi, resoldre un trencaclosques, fer un càlcul, transcriure caràcters) tret que s'ofereixi almenys una d'aquestes alternatives: un altre mètode d'autenticació sense prova cognitiva; un mecanisme d'ajuda (permetre que els gestors de contrasenyes emplenin els camps i que s'hi pugui enganxar text); reconeixement d'objectes (identificar imatges d'objectes comuns); o contingut personal (identificar una imatge que el mateix usuari va proporcionar). El criteri AAA 3.3.9 elimina aquestes dues últimes excepcions. La lliçó 5 aplica aquest criteri als mètodes d'autenticació reals.

Què cal comprovar en un inici de sessió: que els camps d'usuari i contrasenya admeten enganxar i l'emplenament automàtic del navegador o del gestor de contrasenyes (autocomplete="username" i "current-password", sense bloquejar paste); que el segon factor per SMS o aplicació permet enganxar el codi o s'emplena automàticament (autocomplete="one-time-code"); que, si hi ha CAPTCHA, hi ha una alternativa accessible que no sigui una altra prova cognitiva (els CAPTCHA de transcriure text distorsionat, fins i tot en àudio, continuen sent una prova cognitiva); que no es demana un càlcul ni «la tercera lletra de la vostra clau». Els teclats virtuals que obliguen a fer clic en dígits, habituals en banca, són una prova de transcripció que bloqueja els gestors de contrasenyes; incompleixen tret que hi hagi un altre mètode.

Què queda fora i com classificar

Si una persona introdueix un valor vàlid però no el que volia (un altre número de compte), no hi ha cap error detectable: no s'apliquen el 3.3.1 ni el 3.3.3, però sí el 3.3.4 si l'acció és financera. Si el camp no té etiqueta programàtica però té text visible al costat, la fallada és de l'1.3.1 i el 4.1.2, no del 3.3.2. Si la validació es produeix en temps real i el missatge apareix en sortir del camp, el 3.3.1 es compleix si el camp s'identifica i l'error es descriu en text; que el missatge s'anunciï és cosa del 4.1.3, i que no provoqui salts inesperats del focus, del 3.2.1 i el 3.2.2. Per a troballes del 3.3.8, documenta el mètode d'autenticació, quina prova cognitiva exigeix i quina alternativa falta.

Resum

• 3.3.1: el camp erroni s'identifica i l'error es descriu en text, associat al camp i anunciat; 3.3.2: etiquetes i instruccions visibles i permanents (el placeholder no serveix).
• 3.3.3: els missatges d'error suggereixen com corregir, tret de risc per a la seguretat; 3.3.4: accions legals, financeres o de dades reversibles, comprovades o confirmades.
• 3.3.7: les dades ja introduïdes en el mateix procés s'emplenen automàticament o es poden seleccionar, tret que sigui essencial, per seguretat o per caducitat.
• 3.3.8: l'autenticació no exigeix proves cognitives sense alternativa; permetre gestors de contrasenyes i enganxar és la manera habitual de complir; els teclats virtuals obligatoris i els CAPTCHA de transcripció fallen.
• Prova cada formulari buit, amb errors i complet, amb teclat, lector i gestor de contrasenyes.