Diseño de formularios accesibles

Las etiquetas claras indican qué información necesita cada campo de un formulario. Conectar las etiquetas con los campos en el código ayuda a las herramientas de accesibilidad a identificar esos campos. Las instrucciones y los mensajes de respuesta ayudan a las personas a completar el formulario y corregir errores. Comprueba que las etiquetas de tu próximo formulario estén conectadas con sus campos.

Un lector de pantalla es un programa que lee en voz alta la información de una interfaz. Una asociación programática conecta la etiqueta de un campo con ese campo en el código, lo que permite a las herramientas de accesibilidad identificar su propósito. HTML, el lenguaje que se usa para estructurar las páginas web, ofrece el elemento label para hacerlo. Los atributos son ajustes de un elemento HTML: el atributo for de la etiqueta debe coincidir exactamente con el id del campo, que es su identificador. En un formulario hipotético de suscripción a un boletín, la etiqueta «Dirección de correo electrónico» podría usar for="email" junto a un campo con id="email". [2]

Usa conexiones explícitas entre las etiquetas y sus campos siempre que sea posible. Otra opción es colocar tanto el campo como el texto de su etiqueta dentro de un elemento label; la guía indica que las herramientas de accesibilidad suelen ofrecer mejor compatibilidad con las conexiones explícitas. Las etiquetas visibles ayudan a las personas a entender los campos. En situaciones concretas en las que el contenido cercano ya deja claro el propósito de un campo, puedes ocultar visualmente su etiqueta y mantenerla disponible a través del código. Esta opción depende del contexto y no justifica eliminar las etiquetas visibles de todo un formulario. [2]

Agrupa los controles relacionados con fieldset, un elemento HTML que contiene un grupo de controles relacionados, y legend, el elemento que proporciona el encabezado del grupo. Una aplicación hipotética podría agrupar las opciones de tipo de empleo bajo «Tipo de empleo». Incluye instrucciones que expliquen cómo completar los campos. Para una regla hipotética que exija una contraseña de ocho caracteres, haz que la instrucción esté disponible antes de escribir; por ejemplo, cuando el campo reciba el foco, es decir, cuando quede seleccionado para introducir información. Este momento sirve para ilustrar la recomendación de ofrecer instrucciones útiles; no es un criterio universal obligatorio para mostrarlas. [1]

Valida los datos introducidos, es decir, comprueba la información que ingresan los usuarios, y ofrece opciones para deshacer cambios y confirmar los datos introducidos. Avisa a los usuarios de los errores, explica cómo corregirlos y confirma que el proceso se ha completado correctamente. Por ejemplo, un formulario hipotético podría indicar «Introduce una dirección de correo electrónico» cuando falte ese dato obligatorio. La descripción general proporcionada respalda el uso de mensajes que ayuden a corregir errores, pero no establece un lugar obligatorio para mostrarlos ni promete un anuncio concreto del lector de pantalla. [1]

Mantén los formularios breves y pide solo la información necesaria para completar el proceso. Divide los formularios largos en pasos lógicos y muestra a los usuarios su progreso. Siempre que sea posible, evita los límites de tiempo; cuando sea necesario establecer uno, ofrece una forma de desactivarlo o ampliarlo. La guía señala excepciones para los eventos en directo y los casos en los que el tiempo es esencial para que el envío sea válido. [1]

Mantén las etiquetas visualmente cerca de sus campos. Para los idiomas que se leen de izquierda a derecha, como el inglés, la guía describe etiquetas junto a las casillas de verificación y los botones de opción, y encima o a la izquierda de los demás campos. Las etiquetas situadas encima de los campos pueden ayudar a reducir el desplazamiento horizontal, pero su utilidad depende del diseño que las rodea y debe evaluarse en cada caso. Estas recomendaciones no establecen una secuencia universal para crear formularios ni garantizan la accesibilidad para todos los usuarios. [2]

• Orientaciones oficiales, en lugar de evidencia experimental: WAI recomienda etiquetas descriptivas asociadas a los controles. Las conexiones explícitas usan el atributo for de una etiqueta, que coincide con el id del control; esta asociación permite a las herramientas de accesibilidad hacer referencia a la etiqueta correcta y convierte la etiqueta en una zona más amplia en la que se puede hacer clic. [2]
• Orientaciones oficiales: WAI recomienda agrupar los controles relacionados, ofrecer instrucciones, comprobar los datos introducidos y avisar a los usuarios de los errores y de la finalización correcta del proceso. Son prácticas complementarias, sin un orden universal obligatorio para crear el formulario. [1]
• Orientaciones de diseño sujetas al contexto: las etiquetas situadas encima de los campos pueden ayudar a reducir el desplazamiento horizontal, pero WAI señala que su utilidad depende de los campos y del contenido cercanos y debe evaluarse en cada caso. No es una regla universal de colocación. [2]

Estos documentos ofrecen orientaciones oficiales de implementación, no experimentos que demuestren mejoras numéricas en la finalización de formularios, las tasas de error, la cognición o el rendimiento de los lectores de pantalla. No ofrecen garantías de cumplimiento legal, y las técnicas individuales no demuestran que un formulario completo cumpla todos los requisitos de accesibilidad aplicables. Los ejemplos de esta lección son ilustraciones hipotéticas, no resultados de estudios. La entrada bibliográfica anterior «Iniciativa de Accesibilidad Web (WAI) - Conceptos sobre formularios» estaba mal identificada y se sustituye aquí por «Tutorial de formularios» [1]. Se elimina la afirmación anterior atribuida a análisis de auditorías de WebAIM porque los fragmentos proporcionados no la verifican. Estos fragmentos no establecen las palabras ni los anuncios exactos de los lectores de pantalla.