Autenticación accesible (3.3.8), CAPTCHA, selects y selectores de fecha

Hay componentes de formulario que concentran una cantidad desproporcionada de barreras: el inicio de sesión, los CAPTCHA, los desplegables personalizados y los calendarios. Esta lección los recorre uno a uno con las reglas de WCAG 2.2 y las soluciones que funcionan hoy en navegadores y tecnologías de apoyo reales. Aplica la misma regla que usamos con las casillas, los interruptores y los archivos en la lección anterior: primero el control nativo. Cómo encadenar todo en un trámite de varios pasos lo veremos en la siguiente.

3.3.8 Autenticación accesible (mínimo)

Este criterio AA, nuevo en WCAG 2.2, dice que ningún paso de un proceso de autenticación puede exigir una prueba de función cognitiva (recordar una contraseña, resolver un acertijo, transcribir caracteres, hacer un cálculo), salvo que se cumpla al menos una de estas condiciones:

• Existe otro método de autenticación que no requiere esa prueba.
• Hay un mecanismo de ayuda que la resuelve (por ejemplo, permitir que un gestor de contraseñas rellene el campo o pegar desde el portapapeles).
• La prueba consiste en reconocer objetos (imágenes de gatos, por ejemplo).
• La prueba consiste en identificar contenido no textual que la propia persona proporcionó antes (una foto suya).

La versión AAA, 3.3.9 Autenticación accesible (mejorada), elimina las dos últimas excepciones. En la práctica, un formulario de inicio de sesión con usuario y contraseña cumple 3.3.8 siempre que permita pegar y que los gestores de contraseñas funcionen. Lo rompen las webs que bloquean el pegado «por seguridad», que piden la contraseña carácter a carácter en cuadros separados («introduce las posiciones 2, 5 y 7 de tu clave», habitual en banca), o que exigen transcribir un código de la aplicación sin permitir copiarlo.

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

<label for="usuario">Usuario</label>
<input type="text" id="usuario" name="usuario" autocomplete="username">
<label for="clave">Contraseña</label>
<input type="password" id="clave" name="clave" autocomplete="current-password">
<button type="button" aria-pressed="false">Mostrar contraseña</button>

Otras alternativas conformes: enlaces mágicos por correo, autenticación con llaves de acceso (passkeys, WebAuthn), inicio de sesión con certificado digital o Cl@ve, biometría del dispositivo. Lo importante es que al menos una vía no exija recordar ni transcribir.

CAPTCHA

Un CAPTCHA de texto distorsionado es, por definición, una prueba de función cognitiva, y además incumple 1.1.1 Contenido no textual si no ofrece alternativas en otra modalidad. La alternativa de audio clásica es casi inservible para personas sordociegas y muy difícil para quien no es hablante nativo. Opciones por orden de preferencia:

1. Soluciones invisibles basadas en el comportamiento o en pruebas del dispositivo (reCAPTCHA v3, hCaptcha en modo pasivo, Turnstile, Private Access Tokens). En la mayoría de los casos no piden nada a la persona.
2. Campos trampa (honeypot) y límites de frecuencia en el servidor, que detienen la mayoría de los robots sin molestar a nadie.
3. Si hay que usar un desafío visible, ofrecer al menos dos modalidades (visual y auditiva) y una vía de contacto humana si ambas fallan.

Cuando una web usa un CAPTCHA en el inicio de sesión, el CAPTCHA forma parte del proceso de autenticación y queda sujeto a 3.3.8: si no hay un método alternativo ni un mecanismo de ayuda, solo las variantes de reconocimiento de objetos o de contenido personal entran en la excepción, y únicamente en el nivel AA.

Selects nativos frente a personalizados

El <select> nativo es, con diferencia, el control de selección más accesible que existe: funciona con teclado, lector de pantalla, control por voz y en todos los móviles, donde el sistema operativo lo sustituye por su propio selector. Su único problema es que, hasta hace poco, apenas se podía estilizar el desplegable. Hoy CSS permite personalizar bastante el botón, y existe la propiedad appearance: base-select con un soporte todavía parcial que lo hace totalmente estilizable; úsala con prueba de degradación.

Si aun así se construye un select personalizado, el patrón de referencia es el combobox de la ARIA Authoring Practices Guide (se abre en una ventana nueva) (APG): role="combobox" en el elemento que recibe el foco, aria-expanded, aria-controls apuntando a una lista con role="listbox", opciones con role="option" y aria-selected, y navegación con flechas, Inicio, Fin, Escape y búsqueda por letra. Es mucho trabajo y muchos puntos de fallo. En la mayoría de los casos, un <select> nativo bien etiquetado es la decisión correcta, y para listas largas con búsqueda, un <input> con <datalist> o un combobox probado de una librería con reputación de accesibilidad.

<div class="select">
  <div class="select-valor" onclick="abrir()">Provincia</div>
  <ul class="select-opciones">
    <li onclick="elegir('Murcia')">Murcia</li>
    …
  </ul>
</div>

Selectores de fecha

Los calendarios emergentes son uno de los componentes más problemáticos: muchos no se pueden operar con teclado, no anuncian el día enfocado y atrapan el foco. Recomendaciones:

• Permite siempre escribir la fecha directamente en un campo de texto, con el formato indicado en la etiqueta o la ayuda («DD/MM/AAAA»), y trata el calendario como un complemento opcional. Mejor aún, acepta varios formatos y normaliza en el servidor.
• Para fechas que la persona conoce de memoria (nacimiento, caducidad del DNI) un calendario estorba: usa tres campos (día, mes, año) con autocomplete="bday-day", etc., o un solo campo de texto.
• <input type="date"> da un control nativo con buena accesibilidad en móvil y aceptable en escritorio, pero su comportamiento varía entre navegadores y no permite personalizar el formato visible. Pruébalo con el lector de pantalla objetivo antes de adoptarlo.
• Si implementas un calendario, sigue el patrón Date Picker Dialog de la APG: botón de apertura con nombre («Elegir fecha, calendario»), rejilla con role="grid", navegación con flechas entre días, Page Up/Page Down entre meses, Escape para cerrar y devolución del foco al botón, y una región activa que anuncie el mes y año visibles.

Resumen

• 3.3.8 prohíbe exigir memoria o transcripción en la autenticación sin alternativa: permite pegar, deja trabajar a los gestores de contraseñas y usa autocomplete con username, current-password y one-time-code.
• Un CAPTCHA de texto es una barrera doble (1.1.1 y 3.3.8); prefiere soluciones invisibles, honeypots y límites en el servidor.
• El <select> nativo es el control más accesible; un select personalizado exige el patrón combobox completo de la APG.
• Permite escribir la fecha siempre; el calendario es un complemento y, si lo haces, sigue el patrón de la APG.
• Prueba cada uno de estos componentes con teclado, lector de pantalla y en un móvil real antes de darlos por terminados.