Errores de formulario accesibles

Un error que solo se ve —un texto rojo bajo el campo— deja fuera a quien navega con lector de pantalla o solo con teclado. Un formulario accesible ANUNCIA el error, lo ASOCIA a su campo, y lleva el FOCO al primer problema. No es un extra: es lo que separa un formulario usable de uno que frustra. Y es sorprendentemente sencillo con los atributos correctos. Hoy haces tus errores accesibles de verdad —con demo en vivo que puedes probar con el teclado—.

El formulario que también se oye

Un formulario accesible, en vivo

Este playground implementa el patrón completo de errores accesibles. Pruébalo con el teclado (Tab para moverte, Enter para enviar) y, si puedes, con un lector de pantalla:

Envía con los campos vacíos: aparecen los errores Y el foco salta al primer campo con problema (pruébalo con teclado —no tienes que buscar el error con el ratón—). Cada input tiene su <label htmlFor>, su aria-invalid, y su aria-describedby que lo enlaza con el mensaje; el mensaje lleva role="alert" para que el lector de pantalla lo ANUNCIE al aparecer. Corrige y reenvía: cuando todo es válido, un role="status" confirma el éxito. Eso es un formulario que se ve Y se oye.

Los cuatro pilares de un error accesible

Mini-reto

Amplía el formulario accesible: 1) agrega un tercer campo telefono con su label, aria-invalid y aria-describedby, validando que tenga 10 dígitos; 2) ajusta la lógica de foco para que salte al primer error entre los TRES campos; 3) prueba con el teclado (Tab + Enter) que puedes completar y corregir el formulario sin tocar el ratón. Verifica que cada input tiene su label y cada error su role="alert".

Qué sigue

Ya haces formularios validados y accesibles. El último reto de complejidad: los formularios MULTI-PASO (wizards) —registro en varias pantallas, configuración por etapas— donde el estado se acumula entre pasos y hay que poder ir y volver. La próxima lección los arma con las herramientas de estado que ya dominas (spoiler: useReducer y las máquinas de estado del módulo 6).