Formularios accesibles: etiquetas, ayudas y errores

Seis criterios de conformidad para formularios

La WCAG 2.2 es la recomendación actual del W3C para contenido web accesible. Para los textos de un formulario, seis de sus criterios de conformidad son los más importantes:

• 1.3.1 Información y relaciones (nivel A): lo que muestra el diseño, por ejemplo qué etiqueta pertenece a qué campo, también está disponible en el código o en el texto.
• 1.3.5 Identificar el propósito de la entrada (nivel AA): los campos que piden datos sobre el usuario, como el nombre o el correo electrónico, indican su propósito en el código.
• 3.3.1 Identificación de errores (nivel A): si se detecta automáticamente un error de entrada, se nombra el campo y se describe el error en texto.
• 3.3.2 Etiquetas o instrucciones (nivel A): hay etiquetas o instrucciones cuando el contenido requiere que el usuario introduzca datos.
• 3.3.3 Sugerencias ante errores (nivel AA): si se detecta un error y se conoce la corrección, se sugiere, salvo que eso ponga en riesgo la seguridad o la finalidad del contenido.
• 4.1.2 Nombre, función, valor (nivel A): cada control tiene un nombre y una función que el software puede leer.

Cada campo necesita una etiqueta visible

Una etiqueta dice qué va en el campo y sigue visible mientras el usuario escribe. En HTML, une el elemento label con el campo: el atributo for de la etiqueta tiene exactamente el mismo valor que el id del campo. Así los lectores de pantalla leen la etiqueta junto con el campo, y un clic en la etiqueta pone el cursor en el campo. Un botón recibe su etiqueta de su texto, y «Enviar mensaje» dice más que «Enviar». Las etiquetas suelen ir a la derecha de los botones de opción y las casillas, y a la izquierda o encima de los demás campos; las etiquetas encima de los campos ocupan menos ancho.

Un placeholder no es una etiqueta

El texto gris dentro de un campo vacío parece una etiqueta, pero no lo es. El W3C nombra los problemas:

• Desaparece en cuanto alguien escribe, así que cuesta más revisar los datos antes de enviarlos.
• Los navegadores suelen mostrarlo en un color claro con poco contraste.
• Los lectores de pantalla no lo tratan como etiqueta, y el soporte varía.

Usa un placeholder como mucho para un ejemplo y pon todo lo importante en la etiqueta o en una ayuda.

Ayudas y campos obligatorios

• Pon las reglas en una ayuda: el formato de la fecha, la longitud de un número de cliente, lo que necesita una contraseña. En HTML puedes unir la ayuda con aria-describedby, para que los lectores de pantalla la lean después de la etiqueta.
• Indica qué campos son obligatorios y cuáles opcionales. Si usas un asterisco, explícalo una vez al principio del formulario.
• Pon las instrucciones para todo el formulario antes del formulario, por ejemplo sobre un límite de tiempo.
• Mantén las ayudas breves. Demasiadas instrucciones hacen un formulario más difícil, no más fácil.

Agrupa los campos relacionados

Los botones de opción y las casillas que van juntos se agrupan con el elemento fieldset, y el elemento legend da nombre al grupo, por ejemplo «¿Cómo quieres que te contactemos?». El W3C dice que los grupos de botones de opción deberían agruparse siempre así. Mantén la leyenda breve, porque algunos lectores de pantalla la leen con cada campo. Los grupos también ayudan con campos que tienen la misma etiqueta, como la calle en la dirección de envío y en la de facturación.

autocomplete: deja que el navegador ayude

Para los campos que piden datos sobre el usuario, el 1.3.5 pide que su propósito pueda determinarse en el código. La WCAG 2.2 tiene una lista de estos propósitos, basada en la sección de autocompletado de la especificación HTML, como name, given-name, family-name, email, tel, street-address y postal-code. En HTML los indicas con el atributo autocomplete, por ejemplo autocomplete="email". Así los navegadores pueden rellenar valores guardados, lo que ahorra escribir. Los campos que no tratan sobre el usuario no necesitan propósito.

Mensajes de error que ayudan

Un mensaje de error tiene tres tareas: nombrar el campo, decir qué está mal y decir cómo corregirlo. El 3.3.1 pide las dos primeras, en texto, así que un borde rojo o un icono por sí solos no bastan. El 3.3.3 pide la corrección cuando se conoce.

• Muestra el mensaje junto al campo y únelo con aria-describedby, para que los lectores de pantalla lo lean con el campo.
• Después de enviar, muestra arriba, antes del formulario, una lista de todos los errores bajo un título claro. Cada entrada nombra el campo, el problema y la solución, y enlaza al campo.
• Actualiza también el título de la página, por ejemplo «2 errores – Formulario de contacto», y lleva el foco al primer campo con un error.
• Conserva lo que el usuario ya ha introducido. Es un consejo nuestro, no una regla de la WCAG: tener que escribirlo todo de nuevo tras un solo error hace que la gente se rinda.

Revisa tu formulario con Do4U

La herramienta Textos de formulario revisa los textos de un formulario web. Pegas el HTML del formulario o indicas la dirección de la página, y puedes añadir los mensajes de error que muestra tu formulario. El código lee cada campo: su etiqueta y de dónde viene, las ayudas, los placeholders, los campos obligatorios, los valores de autocomplete y los grupos de botones de opción o casillas. Encuentra problemas como un campo sin etiqueta, un placeholder como única etiqueta, campos obligatorios que el texto no menciona, valores de autocomplete que faltan y mensajes de error vagos, cada uno con su criterio de conformidad. La IA sugiere una etiqueta clara, una ayuda breve y un mensaje de error que nombra el campo y dice cómo corregir la entrada. El código comprueba cada sugerencia y crea a partir de tu formulario un borrador HTML mejorado.

Do4U encuentra indicios y crea un borrador; tú revisas y decides. La herramienta comprueba el marcado, no tus estilos, scripts ni el uso con teclado, y no te dice si tu formulario es accesible. Prueba el formulario mejorado con el teclado y con un lector de pantalla.