Ayuda a la entrada de datos: 3.3.1 a 3.3.4, 3.3.7 Entrada redundante y 3.3.8 Autenticación accesible

Los formularios son el lugar donde la web deja de ser lectura y se convierte en gestión: presentar una solicitud, pagar, reservar, identificarse. La pauta 3.3 (ayuda a la entrada de datos) establece cómo deben prevenirse y gestionarse los errores y, desde WCAG 2.2, cómo evitar exigencias innecesarias de memoria y repetición. Esta lección recorre los criterios A y AA de la pauta con el detalle que exige una auditoría de procesos completos.

3.3.1 Identificación de errores (A)

Si se detecta automáticamente un error de entrada, el elemento erróneo se identifica y el error se describe al usuario en texto. Dos condiciones: señalar qué campo falla y explicar qué ocurre. Cómo evaluarlo: envía el formulario vacío, con formatos incorrectos y con valores fuera de rango; comprueba que el mensaje sea textual, visible y asociado programáticamente al campo (aria-describedby) o incluido en su etiqueta; que el lector lo anuncie (foco movido al primer error, resumen con role="alert" o enlaces a los campos); que aria-invalid="true" marque el campo. Fallos: borde rojo sin texto (también 1.4.1); mensaje genérico «hay errores en el formulario» sin indicar cuáles; mensaje que aparece lejos del campo y no se anuncia; errores mostrados solo con icono; mensaje que desaparece a los pocos segundos.

3.3.2 Etiquetas o instrucciones (A)

Cuando el contenido requiere entrada del usuario, se proporcionan etiquetas o instrucciones. El criterio exige que existan y sean visibles (la asociación programática la exigen 1.3.1 y 4.1.2): un campo cuyo único texto es el placeholder incumple 3.3.2, porque la instrucción desaparece al escribir. También cubre los formatos requeridos («dd/mm/aaaa»), los campos obligatorios (indicados de forma comprensible, no solo con asterisco sin explicación) y los grupos de opciones con su pregunta visible. Fallos: placeholders como etiqueta; iconos sin texto; instrucciones de formato que aparecen solo tras el error; etiquetas visuales separadas de su campo.

3.3.3 Sugerencias ante errores (AA)

Si se detecta un error y se conocen sugerencias para corregirlo, se ofrecen, salvo que comprometan la seguridad o el propósito. «Campo incorrecto» no cumple; «Introduzca el DNI con ocho cifras y letra, por ejemplo 12345678A» sí. En contraseñas incorrectas no hay que decir qué parte falla (seguridad). Evaluación: provoca errores concretos (fecha imposible, correo sin arroba, código postal de cuatro dígitos) y comprueba que el mensaje indique cómo corregir.

3.3.4 Prevención de errores (legales, financieros, de datos) (AA)

Para páginas que generan compromisos legales o transacciones financieras, modifican o borran datos controlables por el usuario, o envían respuestas de examen, debe cumplirse al menos una de tres: la acción es reversible; los datos se comprueban y el usuario puede corregirlos; o existe un mecanismo de revisión y confirmación antes de finalizar. Dónde aplica: pago, firma y presentación de solicitudes en sede electrónica, baja de servicios, borrado de cuenta, envío de reclamaciones. Fallos: botón «Presentar» que registra la solicitud sin pantalla de resumen ni posibilidad de anulación; compra en un clic sin confirmación ni cancelación.

<label for="dni">DNI <span>(obligatorio, ocho cifras y letra)</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 debe tener ocho cifras seguidas de una letra, por ejemplo 12345678A.
</p>

3.3.7 Entrada redundante (A) — nuevo en 2.2

La información que el usuario ya ha introducido o se le ha proporcionado en el mismo proceso debe autocompletarse o estar disponible para seleccionarla, salvo que volver a introducirla sea esencial (por ejemplo, en un juego de memoria), sea necesaria para garantizar la seguridad del contenido, o la información anterior ya no sea válida. El caso típico: dirección de envío y de facturación («usar la misma dirección» con una casilla), datos personales pedidos en el paso 1 y de nuevo en el paso 4, correo electrónico repetido en pantallas sucesivas. Evaluación: recorre cada proceso anotando qué datos se piden más de una vez y si existe autocompletado o selección; recuerda que se refiere al mismo proceso (una sesión), no a visitas distintas.

3.3.8 Autenticación accesible (mínimo) (AA) — nuevo en 2.2

Ningún paso de un proceso de autenticación puede exigir una prueba de función cognitiva (recordar una contraseña o un código, resolver un rompecabezas, hacer un cálculo, transcribir caracteres) salvo que se ofrezca al menos una de estas alternativas: otro método de autenticación sin prueba cognitiva; un mecanismo de ayuda (permitir que gestores de contraseñas rellenen los campos y que se pueda pegar texto en ellos); reconocimiento de objetos (identificar imágenes de objetos comunes); o contenido personal (identificar una imagen que el propio usuario proporcionó). El criterio AAA 3.3.9 elimina estas dos últimas excepciones. La lección 5 aplica este criterio a los métodos de autenticación reales.

Qué comprobar en un login: que los campos de usuario y contraseña admiten pegado y autocompletado del navegador o del gestor de contraseñas (autocomplete="username" y "current-password", sin bloquear paste); que el segundo factor por SMS o aplicación permite pegar el código o se autocompleta (autocomplete="one-time-code"); que si hay CAPTCHA, existe alternativa accesible que no sea otra prueba cognitiva (los CAPTCHA de transcribir texto distorsionado, incluso en audio, siguen siendo prueba cognitiva); que no se pide un cálculo ni «la tercera letra de su clave». Los teclados virtuales que obligan a hacer clic en dígitos, habituales en banca, son una prueba de transcripción que bloquea a los gestores de contraseñas; incumplen salvo que exista otro método.

Qué queda fuera y cómo clasificar

Si una persona introduce un valor válido pero no el que quería (otro número de cuenta), no hay error detectable: no aplican 3.3.1 ni 3.3.3, pero sí 3.3.4 si la acción es financiera. Si el campo carece de etiqueta programática pero tiene texto visible al lado, el fallo es 1.3.1 y 4.1.2, no 3.3.2. Si la validación ocurre en tiempo real y el mensaje aparece al salir del campo, 3.3.1 se cumple si el campo se identifica y el error se describe en texto; que el mensaje se anuncie es cosa de 4.1.3, y que no provoque saltos inesperados del foco, de 3.2.1 y 3.2.2. Para hallazgos de 3.3.8, documenta el método de autenticación, qué prueba cognitiva exige y qué alternativa falta.

Resumen

• 3.3.1: el campo erróneo se identifica y el error se describe en texto, asociado al campo y anunciado; 3.3.2: etiquetas e instrucciones visibles y permanentes (el placeholder no vale).
• 3.3.3: los mensajes de error sugieren cómo corregir, salvo riesgo de seguridad; 3.3.4: acciones legales, financieras o de datos reversibles, comprobadas o confirmadas.
• 3.3.7: los datos ya introducidos en el mismo proceso se autocompletan o se pueden seleccionar, salvo esencial, seguridad o caducidad.
• 3.3.8: la autenticación no exige pruebas cognitivas sin alternativa; permitir gestores de contraseñas y pegado es la forma habitual de cumplir; los teclados virtuales obligatorios y los CAPTCHA de transcripción fallan.
• Prueba cada formulario vacío, con errores y completo, con teclado, lector y gestor de contraseñas.