Accesibilidad ≠ Overlay: cuando un formulario no se puede completar con un lector de pantalla
Un formulario accesible no es solo una sucesión de casillas. Es un proceso que cualquier persona debe poder comprender, completar, revisar y enviar con su teclado y su lector de pantalla.
El problema empieza antes de escribir
Un campo puede verse claramente en pantalla y, sin embargo, anunciarse únicamente como «cuadro de edición». Sin una etiqueta asociada, la persona no sabe si debe escribir su nombre, su correo o un número de teléfono.
Etiquetas, instrucciones y campos obligatorios
Cada control necesita un nombre accesible, visible cuando corresponda y asociado mediante HTML. Los campos obligatorios, el formato esperado y las instrucciones deben comunicarse antes de que se produzca un error; el marcador de posición no sustituye a una etiqueta.
El orden del teclado también importa
La tecla Tab debe recorrer los controles en un orden lógico. Los selectores, casillas de verificación, botones y calendarios han de poder utilizarse sin ratón, con un foco visible y sin saltos inesperados.
Errores que se pueden entender y corregir
Un borde rojo no explica por qué falla un campo. El formulario debe identificar el error mediante texto, relacionarlo con el control afectado y permitir corregirlo sin perder los datos ya introducidos. Los mensajes dinámicos deben anunciarse adecuadamente.
Antes de enviar: revisar y confirmar
En compras, trámites y operaciones importantes conviene ofrecer revisión y confirmación, especialmente cuando el envío puede tener consecuencias. Un botón «Enviar» necesita un nombre claro y el resultado de la operación debe comunicarse de forma perceptible.
Qué dicen las WCAG
Las WCAG 2.2 incluyen requisitos relevantes sobre etiquetas e instrucciones (3.3.2), identificación de errores (3.3.1), nombre, función y valor de los controles (4.1.2) y uso del teclado (2.1.1). Cumplirlos exige comprobar el comportamiento real, no solo el aspecto del formulario.
Cómo ayuda Blind Reader
Blind Reader puede orientar sobre el propósito de la página, facilitar la localización de formularios, acompañar la navegación y ayudar con la interacción por voz. También incorpora correcciones automáticas de determinadas barreras, como campos obligatorios que necesitan anunciarse mejor. Estas mejoras se complementan con formularios bien construidos.
Una prueba sencilla antes de publicar
Intenta completar el formulario con teclado y con NVDA, VoiceOver u otro lector de pantalla: identifica cada campo, provoca un error, corrígelo y confirma el envío. Si alguna etapa no se entiende o no puede completarse, todavía hay una barrera que resolver.
Fuentes y referencias
La accesibilidad de un formulario se demuestra cuando la persona puede terminar la tarea, no cuando el formulario simplemente aparece en pantalla.
Entrega 18 · Accesibilidad ≠ Overlay