React: estados de error que no rompen la accesibilidad

Validar un formulario de email parece una tarea pequeña: leer el valor, llamar a una API y mostrar un mensaje. En una interfaz real, sin embargo, el estado de error puede mover todo el layout, robar el foco del teclado o dejar a un lector de pantalla sin contexto.

En proyectos de frontend he encontrado que el problema suele estar en mezclar tres cosas: el estado de red, la validación del campo y la decisión de dónde debe continuar la atención del usuario. Separarlas produce una interfaz más tranquila y también facilita las pruebas.

El problema no es solo el mensaje rojo

Un mensaje visual como “Introduce un email válido” no garantiza que el formulario sea comprensible. El campo debe anunciar su relación con el error, el foco no debe saltar sin motivo y el mensaje debe desaparecer cuando el valor vuelve a ser válido.

Esto importa tanto en un registro normal como en pruebas con un generador de correo falso. Si el equipo usa un correo temporal desechable para verificar un flujo, la UI debe explicar si está validando el formato, esperando el mensaje o mostrando un fallo del servidor. “Algo salió mal” no es un estado útil.

También conviene que el error no cambie la altura de una tarjeta de forma brusca. Una pequeña reserva de espacio con CSS, o un mensaje que aparece dentro de un bloque estable, reduce los saltos visuales. Es un detalle de diseño que se nota mucho en móvil.

Un modelo de estado pequeño y explícito

Para un formulario de email, suelo separar el estado en cuatro partes:

• value: el contenido actual del campo.
• error: un error de validación que la persona puede corregir.
• status: idle, loading, success o server-error.
• submitted: si ya intentó enviar el formulario.

No hace falta una librería grande para esto. Lo importante es que cada combinación tenga una salida visible y accesible. Por ejemplo, un campo vacío antes del primer intento no tiene por qué parecer inválido. Después de pulsar el botón, sí necesita una explicación.

Este mismo principio sirve para una bandeja de pruebas. Cuando se espera un correo, el estado de carga debe tener un texto estable y no bloquear toda la página. Para el contexto de operaciones, resulta útil separar límites claros para las alertas de email de los mensajes que realmente puede resolver la persona en la pantalla.

Código: validar sin mover el foco

Un ejemplo pequeño con React puede ser suficiente:

function EmailField({ value, error, onChange }) {
  const errorId = "signup-email-error";

  return (
    <div className="field">
      <label htmlFor="signup-email">Email</label>
      <input
        id="signup-email"
        name="email"
        type="email"
        value={value}
        onChange={onChange}
        aria-invalid={Boolean(error)}
        aria-describedby={error ? errorId : undefined}
        autoComplete="email"
      />
      <p id={errorId} className="field__message" aria-live="polite">
        {error || " "}
      </p>
    </div>
  );
}

El espacio no separable mantiene una zona de mensaje aunque no exista error; así el contenido de abajo no salta al validar. aria-describedby solo se añade cuando hay algo que describir, y aria-live="polite" permite anunciar el cambio sin interrumpir una lectura importante.

Tras un error de formato, mantendría el foco en el input. Tras un error del servidor, mostraría un mensaje junto al botón y dejaría que la persona decida si revisa el campo o reintenta. Enviar el foco automáticamente al principio del formulario puede parecer servicial, pero suele ser confuso cuando el usuario ya está trabajando más abajo.

Cómo probar la experiencia completa

Una prueba útil no solo comprueba que existe el texto del error. Comprueba la secuencia:

1. El formulario se carga sin errores anunciados.
2. El usuario pulsa enviar con un valor inválido.
3. El campo conserva el foco y expone aria-invalid="true".
4. El mensaje está conectado mediante aria-describedby.
5. Un valor válido elimina el error sin dejar texto antiguo.
6. Un fallo de red muestra una acción de recuperación clara.

En pruebas de integración, puedes verificar también que el botón tiene un estado de carga y que no permite dobles envíos. Para diagnosticar el backend, las trazas útiles para seguir una cola de email ayudan a separar un problema de entrega de un problema de interfaz.

Los nombres de prueba deben parecerse a los casos reales, pero no conviene poner direcciones personales. Un fixture como [e-mail] hace explícito que es un dato de prueba. Si alguien escribe por error “tempail mail” o “temp gamil com”, la validación debe responder con la misma claridad que para cualquier otra entrada, sin asumir que el usuario conoce la marca o la intención.

Q&A rápido

¿Debo enfocar el mensaje de error?

No siempre. En un error de campo, conserva el foco en el campo. Solo mueve el foco a un resumen si hay varios errores y ese resumen ofrece una navegación clara hacia cada uno.

¿aria-live reemplaza a un texto visible?

No. Es una ayuda para comunicar cambios, no un sustituto del diseño. El mensaje debe seguir siendo visible, tener contraste suficiente y explicar una acción concreta.

¿Qué hago con un email temporal desechable en producción?

Las reglas de negocio deben decidir si se acepta o se bloquea, pero la interfaz tiene que comunicar la decisión sin revelar datos innecesarios. Para una prueba puntual, tempmail so puede servir como contexto de un buzón aislado; no debe ocultar los requisitos del flujo.

Conclusión

Los formularios accesibles no necesitan estados complicados. Necesitan estados previsibles: un error conectado al campo, un foco que respeta la intención y una zona de mensaje que no reacomoda toda la página. En React, modelar esas decisiones de forma explícita mejora la experiencia, hace el CSS más estable y convierte los tests de email en una comprobación del flujo completo, no solo de una cadena roja.