Formularios accesibles: etiquetas, errores y teclado

¿Qué hace que un formulario sea accesible?

Los formularios suelen ser el punto en el que una web cumple su finalidad: contacto, pedido, registro, solicitud. Si alguien fracasa aquí, termina todo el proceso. Los buenos formularios no solo ayudan a quienes usan lector de pantalla, sino también a las personas con dificultades de aprendizaje, a las personas mayores y a quien escribe en el móvil sobre la marcha.

Un formulario accesible tiene etiquetas visibles y asociadas técnicamente, instrucciones comprensibles y mensajes de error útiles, y se puede usar por completo con el teclado. En las WCAG afecta sobre todo a los criterios 1.3.1 (estructura), 2.1.1 (teclado), 3.3.1 a 3.3.3 (errores, etiquetas, sugerencias de corrección) y 4.1.2 (nombre, función, valor).

¿Cómo etiqueto correctamente los campos de un formulario?

Asocia cada campo de entrada con un label mediante valores for e id coincidentes, por ejemplo <label for="email">Correo electrónico</label> y <input id="email" type="email">. Así, el lector de pantalla lee la etiqueta, y un clic en ella coloca el foco en el campo.

Un texto de marcador de posición (placeholder) desaparece al escribir y no sustituye a la etiqueta. Además, la etiqueta debe contener la palabra que se ve. Quien diga «Clic Correo electrónico» con el control por voz tiene que llegar así al campo. Los botones también necesitan un texto claro, como «Enviar mensaje», en lugar de solo una flecha.

Si por motivos de diseño no hay una etiqueta visible, por ejemplo en un campo de búsqueda con lupa, el campo necesita igualmente un nombre accesible, por ejemplo mediante una etiqueta oculta visualmente o aria-label. Un texto visible sigue siendo la mejor solución, porque ayuda a todo el mundo. En los campos de texto, la etiqueta suele ir encima o a la izquierda; en las casillas de verificación y los botones de opción, a la derecha.

¿Cómo señalo los campos obligatorios?

Explica al principio cómo marcas los campos obligatorios, por ejemplo «Los campos con * son obligatorios». Aún más claro es añadir «(obligatorio)» en la etiqueta. El atributo HTML required transmite además la información a las tecnologías de apoyo.

No señales los campos obligatorios solo con color. Indica los formatos esperados antes de la entrada, por ejemplo «Fecha en formato DD/MM/AAAA». Pide solo los datos que tu proceso necesita de verdad. Si casi todos los campos son obligatorios, es mejor marcar los pocos opcionales con «(opcional)».

¿Cuándo necesito fieldset y legend?

Cuando varios campos van juntos, los agrupas con fieldset y das al grupo un título con legend. Lo típico son los botones de opción como «Forma de contacto preferida: teléfono, correo electrónico» o los grupos de casillas de verificación.

Sin el nombre del grupo, alguien con lector de pantalla solo oye «Teléfono, botón de opción» y no sabe a qué se refiere la pregunta. Los bloques de dirección, como la dirección de envío y la de facturación, también se entienden mejor agrupados. Pero no anides grupos sin necesidad, porque algunos lectores de pantalla leen el nombre del grupo en cada campo.

¿Cómo redacto mensajes de error útiles?

Valida los datos al enviar o al salir de un campo, no con cada pulsación de tecla. Los mensajes que aparecen mientras se escribe interrumpen constantemente a quienes usan lector de pantalla. Después de enviar, coloca el foco en el resumen de errores o en el primer campo con error, para que nadie tenga que buscar.

1. 1Nombra el campo afectado y la causa concreta: «La dirección de correo electrónico no contiene el signo @».
2. 2Describe una posible corrección, por ejemplo el formato de fecha esperado.
3. 3Señala los errores con texto y no solo con color rojo.
4. 4Asocia técnicamente los textos de error y las indicaciones adicionales al campo, por ejemplo mediante aria-describedby.
5. 5Si hay varios errores, ayuda un resumen encima del formulario con enlaces a los campos.
6. 6Conserva los datos ya introducidos, siempre que el proceso lo permita.
7. 7Anuncia los mensajes de estado como «Mensaje enviado» de forma que los lectores de pantalla los lean sin mover el foco (WCAG 4.1.3).

¿Cómo ayuda autocomplete a rellenar formularios?

Con el atributo autocomplete le dices al navegador qué dato espera un campo, por ejemplo autocomplete="name", "email" o "postal-code". En el nivel AA, el criterio 1.3.5 de las WCAG exige que la finalidad de estos campos con datos personales se pueda determinar técnicamente.

Así, el navegador puede rellenar los campos automáticamente. Eso ahorra escribir y ayuda a las personas con limitaciones motoras o cognitivas. En la misma línea, el criterio 3.3.7 de las WCAG 2.2 exige que los datos ya introducidos en el mismo proceso no tengan que escribirse de nuevo. No desactives el autocompletado sin motivo con autocomplete="off".

¿Qué hay que tener en cuenta con los límites de tiempo, los CAPTCHA y el inicio de sesión?

Si un formulario caduca tras un tiempo, por regla general las personas usuarias deben poder desactivar, ajustar o ampliar el límite (WCAG 2.2.1). Si no, precisamente quien escribe más despacio pierde lo que ha introducido. Indica antes cuánto tiempo hay disponible.

En el inicio de sesión, el criterio 3.3.8 de las WCAG prohíbe las pruebas de función cognitiva, como acertijos o copiar caracteres distorsionados, si no hay una alternativa o ayuda. Permite pegar contraseñas y usar gestores de contraseñas. Los formularios largos los divides en pasos y muestras el progreso.

En los pedidos y otras entradas con consecuencias jurídicas o económicas, el criterio 3.3.4 de las WCAG exige que el envío se pueda deshacer, que se revisen los datos o que un resumen antes de enviar permita corregirlos.

¿Cómo pruebo un formulario?

Llega a los campos y al botón de envío con el teclado. Envía a propósito datos incompletos y corrige el error. Comprueba después si se reconoce un mensaje de confirmación. Incluye también los campos que aparecen de forma dinámica y repite el recorrido con un lector de pantalla. Fíjate en que el orden del foco siga el orden visible, sobre todo en los formularios a dos columnas.

El análisis de Accessonaut detecta automáticamente, entre otras cosas, los campos de formulario sin etiqueta. No valora si las instrucciones y los mensajes de error son comprensibles; para eso necesitas la revisión manual.

Comprueba además con una ampliación del 200 % si las etiquetas y los mensajes de error siguen visibles junto a sus campos. En el móvil ayudan los tipos de entrada adecuados, como type="email" o type="tel", porque el teclado en pantalla ofrece entonces los caracteres correctos.