Diseñar formularios: etiquetas, ayudas y errores (3.3.1 a 3.3.8)

Los formularios son donde la accesibilidad se convierte en derecho efectivo: pedir una cita médica, presentar una solicitud, comprar, reclamar. También son el lugar donde más barreras se acumulan: etiquetas que desaparecen, errores que solo se indican en rojo, campos que piden el mismo dato tres veces, contraseñas imposibles. Esta lección recorre los criterios de la pauta 3.3 «Ayuda a la entrada de datos» desde el punto de vista del diseño, incluidos los dos criterios nuevos de WCAG 2.2.

Etiquetas e instrucciones (3.3.2)

El criterio 3.3.2 Etiquetas o instrucciones (A) exige que se proporcionen etiquetas o instrucciones cuando el contenido requiere entrada de datos. Decisiones de diseño:

• Etiqueta visible, siempre, encima o a la izquierda del campo. El placeholder no es una etiqueta: desaparece al escribir, suele tener contraste insuficiente y no lo leen de forma fiable todas las tecnologías de apoyo. Los diseños «flotantes» (la etiqueta sube al escribir) son aceptables si la etiqueta sigue visible y legible en todo momento.
• Instrucciones antes del campo, no después: formato esperado («DD/MM/AAAA»), requisitos («mínimo 8 caracteres»), ejemplos. Si van después, quien usa lector de pantalla las descubre tarde.
• Campos obligatorios indicados con texto o un asterisco explicado al inicio del formulario. Si casi todos son obligatorios, marca los opcionales.
• Agrupa campos relacionados (dirección, fechas, opciones de un mismo tema) con un título de grupo visible, que en código será fieldset y legend.
• Una columna. Varias columnas se leen en orden confuso con zoom y lector de pantalla.

Errores: detectarlos, describirlos, sugerir (3.3.1, 3.3.3)

El criterio 3.3.1 Identificación de errores (A) exige que, si se detecta automáticamente un error, el elemento erróneo se identifique y el error se describa en texto. El criterio 3.3.3 Sugerencias ante errores (AA) añade que, si se conoce cómo corregirlo, se sugiera la corrección (salvo que comprometa la seguridad o el propósito). Patrón de diseño recomendado:

1. Resumen de errores al principio del formulario tras enviarlo, con el foco movido a él, con cada error enlazado a su campo.
2. Mensaje junto al campo, en texto, con icono, no solo con color (1.4.1). En código se vinculará con aria-describedby y aria-invalid.
3. Texto que explica qué está mal y cómo arreglarlo: «Escribe la fecha con el formato DD/MM/AAAA, por ejemplo 05/03/1990», no «Campo inválido».
4. Conservar los datos introducidos: nunca vaciar el formulario tras un error.
5. Validación en el momento adecuado: al salir del campo o al enviar; nunca con cada tecla pulsada, que genera errores antes de terminar de escribir.

<!-- Mensaje de error correcto: visible, en texto, vinculado al campo -->
<label for="email">Correo electrónico (obligatorio)</label>
<input id="email" type="email" autocomplete="email"
       aria-describedby="email-error" aria-invalid="true">
<p id="email-error">Error: falta el símbolo @. Ejemplo: nombre@dominio.es</p>

Prevenir errores graves (3.3.4)

El criterio 3.3.4 Prevención de errores (legales, financieros, datos) (AA) exige que, en transacciones con consecuencias legales o económicas o que modifiquen datos del usuario, se cumpla al menos una de tres: la acción es reversible, los datos se comprueban y se da oportunidad de corregirlos, o hay un paso de confirmación antes de finalizar. En diseño: una pantalla de revisión antes de pagar o firmar, con posibilidad de volver a cada paso, y confirmaciones explícitas para borrar datos.

Novedades de WCAG 2.2

3.3.7 Entrada redundante (A)

La información que la persona ya ha introducido en un proceso no debe pedirse de nuevo: se rellena automáticamente o se ofrece para seleccionar («Usar la misma dirección para el envío»). Excepciones: cuando volver a introducirla es esencial (por ejemplo, en un juego de memoria), cuando lo exige la seguridad (confirmar una contraseña nueva que no se muestra en pantalla o volver a escribir la actual) o cuando el dato anterior ya no es válido. Beneficia a personas con dificultades de memoria, de atención o de movilidad, para quienes repetir datos es un coste real.

3.3.8 Autenticación accesible (mínimo) (AA)

Ningún paso de un proceso de autenticación puede exigir una prueba de función cognitiva (recordar una contraseña, transcribir caracteres, resolver un puzle, hacer un cálculo) salvo que se cumpla al menos una condición: existe un método alternativo sin prueba cognitiva; existe un mecanismo de ayuda (por ejemplo, permitir pegar la contraseña o usar un gestor de contraseñas); la prueba consiste en reconocer objetos; o la prueba consiste en reconocer contenido no textual proporcionado por la propia persona (su foto). Consecuencias prácticas de diseño:

• Nunca bloquear el pegado en los campos de contraseña ni los gestores de contraseñas.
• Ofrecer inicio de sesión con enlace mágico por correo, biometría del dispositivo, passkeys o códigos de un solo uso que se puedan copiar y pegar.
• Si hay CAPTCHA, que no sea de transcripción, o que exista alternativa.
• Los códigos por SMS son una prueba cognitiva salvo que se puedan pegar o se autocompleten.

El criterio 3.3.9 (AAA) elimina las excepciones de reconocimiento de objetos y de contenido propio.

Relacionado: el criterio 1.3.5 Identificar el propósito de la entrada (AA) exige que los campos de datos personales habituales (nombre, correo, teléfono, dirección) declaren su propósito, en la práctica con el atributo autocomplete; documenta en el diseño qué dato recoge cada campo.

Resumen

• 3.3.2 Etiquetas o instrucciones (A): etiquetas visibles y permanentes, instrucciones antes del campo, obligatorios indicados, una columna.
• 3.3.1 Identificación de errores (A) y 3.3.3 Sugerencias ante errores (AA): resumen de errores, mensaje en texto junto al campo, cómo corregirlo, sin vaciar datos.
• 3.3.4 Prevención de errores (AA): reversible, comprobado o confirmado en transacciones legales, financieras o de datos.
• 3.3.7 Entrada redundante (A, nuevo): no pedir dos veces lo ya introducido en el mismo proceso.
• 3.3.8 Autenticación accesible (mínimo) (AA, nuevo): sin pruebas cognitivas obligatorias; permitir pegar, gestores de contraseñas, passkeys o alternativas. 1.3.5: campos con autocomplete.