Autenticació accessible (3.3.8), CAPTCHA, selects i selectors de data

Hi ha components de formulari que concentren una quantitat desproporcionada de barreres: l'inici de sessió, els CAPTCHA, els desplegables personalitzats i els calendaris. Aquesta lliçó els recorre un per un amb les regles de les WCAG 2.2 i les solucions que funcionen avui en navegadors i tecnologies de suport reals. Aplica la mateixa regla que vam fer servir amb les caselles, els interruptors i els fitxers a la lliçó anterior: primer el control natiu. Com encadenar-ho tot en un tràmit de diversos passos ho veurem a la següent.

3.3.8 Autenticació accessible (mínim)

Aquest criteri AA, nou a les WCAG 2.2, diu que cap pas d'un procés d'autenticació no pot exigir una prova de funció cognitiva (recordar una contrasenya, resoldre una endevinalla, transcriure caràcters, fer un càlcul), tret que es compleixi almenys una d'aquestes condicions:

• Hi ha un altre mètode d'autenticació que no requereix aquesta prova.
• Hi ha un mecanisme d'ajuda que la resol (per exemple, permetre que un gestor de contrasenyes empleni el camp o enganxar des del porta-retalls).
• La prova consisteix a reconèixer objectes (imatges de gats, per exemple).
• La prova consisteix a identificar contingut no textual que la mateixa persona va proporcionar abans (una foto seva).

La versió AAA, 3.3.9 Autenticació accessible (millorada), elimina les dues últimes excepcions. A la pràctica, un formulari d'inici de sessió amb usuari i contrasenya compleix el 3.3.8 sempre que permeti enganxar i que els gestors de contrasenyes funcionin. El trenquen els webs que bloquegen l'enganxat «per seguretat», que demanen la contrasenya caràcter per caràcter en quadres separats («introdueix les posicions 2, 5 i 7 de la teva clau», habitual a la banca), o que exigeixen transcriure un codi de l'aplicació sense permetre copiar-lo.

<input type="password" id="clave" autocomplete="off"
       onpaste="return false">

<label for="usuario">Usuari</label>
<input type="text" id="usuario" name="usuario" autocomplete="username">
<label for="clave">Contrasenya</label>
<input type="password" id="clave" name="clave" autocomplete="current-password">
<button type="button" aria-pressed="false">Mostra la contrasenya</button>

Altres alternatives conformes: enllaços màgics per correu, autenticació amb claus d'accés (passkeys, WebAuthn), inici de sessió amb certificat digital o Cl@ve, biometria del dispositiu. L'important és que almenys una via no exigeixi recordar ni transcriure.

CAPTCHA

Un CAPTCHA de text distorsionat és, per definició, una prova de funció cognitiva, i a més incompleix l'1.1.1 Contingut no textual si no ofereix alternatives en una altra modalitat. L'alternativa d'àudio clàssica és gairebé inservible per a persones sordcegues i molt difícil per a qui no és parlant nadiu. Opcions per ordre de preferència:

1. Solucions invisibles basades en el comportament o en proves del dispositiu (reCAPTCHA v3, hCaptcha en mode passiu, Turnstile, Private Access Tokens). En la majoria dels casos no demanen res a la persona.
2. Camps trampa (honeypot) i límits de freqüència al servidor, que aturen la majoria dels robots sense molestar ningú.
3. Si cal fer servir un desafiament visible, oferir almenys dues modalitats (visual i auditiva) i una via de contacte humana si totes dues fallen.

Quan un web fa servir un CAPTCHA a l'inici de sessió, el CAPTCHA forma part del procés d'autenticació i queda subjecte al 3.3.8: si no hi ha un mètode alternatiu ni un mecanisme d'ajuda, només les variants de reconeixement d'objectes o de contingut personal entren a l'excepció, i únicament al nivell AA.

Selects natius davant de personalitzats

El <select> natiu és, de lluny, el control de selecció més accessible que existeix: funciona amb teclat, lector de pantalla, control per veu i a tots els mòbils, on el sistema operatiu el substitueix pel seu propi selector. El seu únic problema és que, fins fa poc, a penes es podia estilitzar el desplegable. Avui el CSS permet personalitzar força el botó, i existeix la propietat appearance: base-select, amb un suport encara parcial, que el fa totalment estilitzable; fes-la servir amb prova de degradació.

Si tot i així es construeix un select personalitzat, el patró de referència és el combobox de l'ARIA Authoring Practices Guide (s'obre en una finestra nova) (APG): role="combobox" a l'element que rep el focus, aria-expanded, aria-controls apuntant a una llista amb role="listbox", opcions amb role="option" i aria-selected, i navegació amb fletxes, Inici, Fi, Escape i cerca per lletra. És molta feina i molts punts de fallada. En la majoria dels casos, un <select> natiu ben etiquetat és la decisió correcta, i per a llistes llargues amb cerca, un <input> amb <datalist> o un combobox provat d'una biblioteca amb reputació d'accessibilitat.

<div class="select">
  <div class="select-valor" onclick="abrir()">Província</div>
  <ul class="select-opciones">
    <li onclick="elegir('Murcia')">Múrcia</li>
    …
  </ul>
</div>

Selectors de data

Els calendaris emergents són un dels components més problemàtics: molts no es poden fer funcionar amb teclat, no anuncien el dia enfocat i atrapen el focus. Recomanacions:

• Permet sempre escriure la data directament en un camp de text, amb el format indicat a l'etiqueta o a l'ajuda («DD/MM/AAAA»), i tracta el calendari com un complement opcional. Millor encara, accepta diversos formats i normalitza al servidor.
• Per a dates que la persona coneix de memòria (naixement, caducitat del DNI) un calendari fa nosa: fes servir tres camps (dia, mes, any) amb autocomplete="bday-day", etc., o un sol camp de text.
• <input type="date"> dona un control natiu amb bona accessibilitat al mòbil i acceptable a l'escriptori, però el seu comportament varia entre navegadors i no permet personalitzar el format visible. Prova'l amb el lector de pantalla objectiu abans d'adoptar-lo.
• Si implementes un calendari, segueix el patró Date Picker Dialog de l'APG: botó d'obertura amb nom («Tria una data, calendari»), graella amb role="grid", navegació amb fletxes entre dies, Page Up/Page Down entre mesos, Escape per tancar i retorn del focus al botó, i una regió activa que anunciï el mes i l'any visibles.

Resum

• El 3.3.8 prohibeix exigir memòria o transcripció a l'autenticació sense alternativa: permet enganxar, deixa treballar els gestors de contrasenyes i fes servir autocomplete amb username, current-password i one-time-code.
• Un CAPTCHA de text és una barrera doble (1.1.1 i 3.3.8); prefereix solucions invisibles, honeypots i límits al servidor.
• El <select> natiu és el control més accessible; un select personalitzat exigeix el patró combobox complet de l'APG.
• Permet sempre escriure la data; el calendari és un complement i, si el fas, segueix el patró de l'APG.
• Prova cadascun d'aquests components amb teclat, lector de pantalla i en un mòbil real abans de donar-los per acabats.