¿Qué son los formularios accesibles?

¿Qué son los formularios accesibles?

Un formulario accesible puede ser entendido, recorrido y completado por todos, incluidas las personas que usan teclado, lector de pantalla, control por voz, zoom o dispositivos de conmutación. En la práctica significa que cada campo tiene una etiqueta programática, los campos relacionados están agrupados, los errores se identifican con texto y una sugerencia para corregirlos, y todo funciona sin ratón.

Qué hay que cuidar

• Etiquetas. Usa un elemento label real, asociado al campo con for e id. WCAG 3.3.2 (nivel A) exige etiquetas o instrucciones cuando el contenido admite entrada, y 1.3.1 (nivel A) exige que la relación se pueda determinar mediante programación. Un placeholder no es una etiqueta: desaparece en cuanto se escribe.
• Agrupación. Agrupa controles relacionados, como botones de radio, en un fieldset con legend, tal como describen las técnicas del W3C para 1.3.1.
• Propósito de la entrada. Añade el valor autocomplete adecuado (given-name, email, tel) para que navegadores y tecnologías de apoyo sepan qué pide cada campo (1.3.5, nivel AA).
• Errores. Identifica el campo con error y describe el problema con texto (3.3.1, nivel A), y ofrece una sugerencia cuando se conozca (3.3.3, nivel AA). El color por sí solo no basta.
• No obligues a repetir datos. La información ya introducida en el mismo proceso debe rellenarse sola o poder seleccionarse (3.3.7 Entrada redundante, nivel A, novedad de WCAG 2.2).
• Inicio de sesión. No bloquees pegar ni los gestores de contraseñas: 3.3.8 Autenticación accesible (nivel AA) considera una barrera obligar a recordar o transcribir una contraseña si no hay alternativa.
• Nombre, función, valor. Los controles personalizados deben exponer lo mismo a las tecnologías de apoyo (4.1.2, nivel A). Consulta componentes de entrada personalizados y ARIA, y prefiere primero los elementos nativos.

Ejemplo

<label for="email">Correo electrónico</label>
<input id="email" name="email" type="email"
       autocomplete="email" aria-describedby="email-err">
<p id="email-err">Escribe una dirección como nombre@ejemplo.com</p>

La etiqueta se anuncia junto al campo, la ayuda se lee mediante aria-describedby y el navegador puede autocompletar. Comprueba que todos los controles sean alcanzables y estén en un orden lógico: consulta el orden de navegación por teclado.

Errores frecuentes

• El texto del placeholder como única etiqueta.
• Un mensaje como "Entrada no válida" que no dice qué campo ni cómo corregirlo, o un borde rojo sin texto.
• Campos obligatorios marcados solo con color.
• Desactivar el pegado en campos de contraseña o de confirmación de correo.
• Desplegables y selectores de fecha hechos con div sin soporte de teclado ni rol.

Pruebas y monitorización

Las pruebas de accesibilidad automatizadas detectan de forma fiable etiquetas y nombres ausentes, por lo que sirven como control de regresión en formularios. No pueden juzgar si un mensaje de error se entiende o si el orden del tabulador es lógico: recorre también el formulario con la tecla Tab y con un lector de pantalla. El marco general es WCAG. La monitorización de velocidad de página de LoadFocus registra de forma programada la categoría de accesibilidad de Lighthouse de las páginas con tus formularios, de modo que una caída se ve como tendencia. Es un monitor, no una auditoría de accesibilidad. Para herramientas, consulta este repaso de herramientas de pruebas de accesibilidad.

Preguntas frecuentes: formularios accesibles

¿Basta un placeholder como etiqueta?

No. Los placeholders desaparecen al escribir, suelen tener poco contraste y no son un nombre accesible fiable. Usa un elemento label visible.

¿Qué criterios de WCAG afectan a los formularios?

Sobre todo 1.3.1, 1.3.5, 3.3.1, 3.3.2, 3.3.3, 3.3.7, 3.3.8 y 4.1.2, además del manejo por teclado (2.1.1) y el foco visible.

¿Debo usar ARIA en los formularios?

Solo donde el HTML nativo no llegue. Un label, un fieldset y un input nativos ya dan el nombre, la función y el estado correctos. Usa ARIA para widgets personalizados y para vincular ayudas y errores a los campos.

¿Cómo debo mostrar los errores?

Indica con texto qué campo tiene el problema y cómo corregirlo, coloca el mensaje junto al campo y, tras un envío fallido, mueve el foco a un resumen de errores o al primer campo no válido.

¿Puede una herramienta comprobar la accesibilidad de un formulario?

Detecta etiquetas y nombres ausentes, pero no textos poco claros ni un orden confuso. Combínala con pruebas manuales de teclado y lector de pantalla.