Formularios accesibles

Qué falla

La etiqueta no es una etiqueta. Un placeholder, o un texto colocado visualmente al lado del campo sin asociación programática. El campo se anuncia como “campo de edición, vacío” y la persona tiene que adivinar por la posición.

El error es solo visual. El mensaje se pinta en rojo junto al campo. No está asociado al input, no está en una región activa, y el foco no se mueve. Quien usa lector de pantalla pulsa enviar y no oye absolutamente nada: el formulario parece no haber funcionado.

El error no dice nada útil. “Dato no válido” describe un estado. La persona necesita el remedio: el formato esperado, el rango permitido, el motivo del rechazo.

Lo obligatorio se marca con color. Un asterisco rojo sin equivalente textual y sin atributo required.

El campo no declara su propósito. Sin autocomplete, el autorrelleno del navegador no puede ayudar — y eso es una función de accesibilidad antes que una comodidad, porque ahorra teclear a personas con discapacidad motora y cognitiva.

Cómo probarlo

Envía todos los formularios mal, a propósito, con un lector de pantalla funcionando.

1. Envíalo completamente vacío.
2. Envíalo con un campo mal formado: un correo inválido, una contraseña corta, una tarjeta errónea.
3. Escucha. ¿Se anunció algo? ¿Pudiste encontrar el campo al que se refiere sin mirar?
4. Tabula a cada campo con los ojos cerrados. ¿Lo que oyes te dice qué escribir?
5. Comprueba que el autorrelleno del navegador ofrece completar nombre, correo y dirección.

Cómo corregirlo

Asocia todas las etiquetas.

<!-- El placeholder desaparece y no es una etiqueta -->
<input type="email" placeholder="Correo electrónico" />

<!-- Anunciado, clicable y sigue ahí después de escribir -->
<label for="email">Correo electrónico</label>
<input type="email" id="email" name="email" autocomplete="email" />

Ata los errores a su campo, y anúncialos.

<label for="tarjeta">Número de tarjeta</label>
<input
  type="text"
  id="tarjeta"
  name="tarjeta"
  inputmode="numeric"
  autocomplete="cc-number"
  aria-invalid="true"
  aria-describedby="error-tarjeta"
/>
<p id="error-tarjeta" role="alert">
  Escribe los 16 dígitos del anverso de la tarjeta, sin espacios.
</p>

Ahí hay tres cosas trabajando. aria-invalid expone el estado. aria-describedby hace que el mensaje se lea cuando el campo recibe el foco. role="alert" hace que se anuncie cuando aparece.

Al enviar, mueve el foco. Al primer campo con error, o a un resumen de errores al principio del formulario que liste cada problema como un enlace a su campo. El resumen escala mejor en formularios largos y es el patrón que recomienda la mayoría de guías del sector público.

Di cómo arreglarlo, no que está mal. “Escribe una fecha futura” es mejor que “Fecha no válida”. “La contraseña necesita al menos 10 caracteres” es mejor que “La contraseña no cumple los requisitos”.

Nunca bloquees el pegado. Bloquear pegar en un campo de contraseña o de tarjeta rompe los gestores de contraseñas y es una barrera conforme al criterio 3.3.8 Accessible Authentication.

Por qué importa comercialmente

Esta es la categoría donde el trabajo de accesibilidad se paga solo sin necesidad de invocar la ley. Un checkout que anuncia bien sus errores tiene menos abandono para todo el mundo, porque todo el mundo envía un formulario mal de vez en cuando — y la diferencia entre “tu tarjeta ha sido rechazada” y el silencio la nota cualquier cliente.