Un formulario es un elemento que permite que un usuario proporcione datos en un campo o en un grupo de campos. Los formularios pueden ser un solo campo o un formulario complejo de varios pasos con varios campos por página, validación de entrada y un CAPTCHA.
Los formularios se consideran uno de los elementos más difíciles de hacer bien desde una perspectiva de accesibilidad, ya que requieren conocimiento de todos los elementos que ya abordamos, así como reglas adicionales específicas solo para formularios. Con un poco de comprensión y tiempo, puedes crear un formulario accesible que se adapte a ti y a tus usuarios.
Los formularios son el último módulo específico de componentes de este curso. Este módulo se enfoca en los lineamientos específicos para formularios. Sin embargo, los lineamientos anteriores que se encuentran en módulos anteriores, como la estructura del contenido, el foco del teclado y el contraste de color, también se aplican a los elementos de formulario.
Campos
La columna vertebral de los formularios son los campos. Los campos son pequeños patrones interactivos, como un elemento de entrada o un botón de selección, que permiten a los usuarios ingresar contenido o tomar una decisión. Hay una gran variedad de campos de formulario para elegir.
La recomendación predeterminada es usar patrones HTML establecidos en lugar de crear algo personalizado con ARIA, ya que ciertas funciones y características, como los estados, las propiedades y los valores de los campos, están integradas de forma inherente en los elementos HTML. Los campos personalizados requieren que agregues ARIA de forma manual.
No se recomienda: HTML personalizado con ARIA
<div role="form" id="sundae-order-form">
<!-- form content -->
</div>
Recomendado: HTML estándar
<form id="sundae-order-form">
<!-- form content -->
</form>
Además de elegir los patrones de campos de formulario más accesibles, cuando corresponda, también debes agregar atributos de autocompletar HTML a tus campos. Agregar atributos de autocompletar permite una definición o identificación del propósito más detallada para los agentes de usuario y las tecnologías de asistencia (TA).
Los atributos de autocompletar permiten a los usuarios personalizar las presentaciones visuales, por ejemplo, mostrar un ícono de pastel de cumpleaños en un campo con el atributo de autocompletar de cumpleaños (bday) asignado. En general, los atributos de autocompletar facilitan y aceleran el proceso de completar formularios. Esto es especialmente útil para las personas con trastornos cognitivos y de lectura, y para quienes usan TA, como los lectores de pantalla.
<form id="sundae-order-form">
<p>Name: <input type="name" autocomplete="name"></p>
<p>Telephone: <input type="tel" autocomplete="tel"></p>
<p>Email address: <input type="email" autocomplete="email"></p>
</form>
Por último, los campos de formulario no deben producir cambios contextuales cuando reciben el foco o la entrada del usuario, a menos que se le haya advertido al usuario sobre el comportamiento antes de usar el componente. Por ejemplo, un formulario no se debe enviar automáticamente cuando un campo recibe el foco o cuando un usuario agrega contenido al campo.
Etiquetas
Las etiquetas informan al usuario sobre el propósito de un campo, si es obligatorio y también pueden proporcionar información sobre los requisitos del campo, como el formato de entrada. Las etiquetas deben ser visibles en todo momento y describir con precisión el campo del formulario a los usuarios.
Uno de los principios fundamentales de los formularios accesibles es establecer una conexión clara y precisa entre un campo y su etiqueta. Esto es cierto tanto visual como programáticamente. Sin este contexto, es posible que el usuario no comprenda cómo completar los campos del formulario.
<form id="sundae-order-form">
<p><label>Name (required): <input type="name" autocomplete="name" required></label></p>
<p><label>Telephone (required): <input type="tel" autocomplete="tel" required></label></p>
<p><label>Email address: <input type="email" autocomplete="email"></label></p>
</form>
Además, los campos de formulario relacionados, como una dirección de correo postal, deben agruparse de forma visual y programática. Un método es usar el patrón de fieldset y leyenda para agrupar elementos similares.
Descripciones
Las descripciones de los campos son similares a las etiquetas en cuanto a su propósito, ya que se usan para brindar más contexto sobre el campo y los requisitos. Las descripciones de los campos no son obligatorias para la accesibilidad si las etiquetas o las instrucciones del formulario son lo suficientemente descriptivas.
Sin embargo, hay situaciones en las que agregar información adicional es útil para evitar errores en los formularios, como transmitir información sobre la longitud mínima de entrada para un campo de contraseña o indicarle a un usuario qué formato de calendario debe usar (como DD-MM-AAAA).
Existen muchos métodos diferentes que puedes usar para agregar descripciones de campos a tus formularios. Uno de los mejores métodos es agregar un atributo aria-describedby al elemento del formulario, además de un elemento <label>. El lector de pantalla leerá la descripción y la etiqueta.
Si agregas el atributo aria-labelledby a tu elemento, el valor del atributo anulará el texto dentro de tu <label>. Como siempre, prueba el código final con todas las TA que quieras admitir.
Errores
Cuando creas formularios accesibles, hay muchas cosas que puedes hacer para evitar que los usuarios cometan errores. Anteriormente en este módulo, explicamos cómo marcar claramente los campos, crear etiquetas de identificación y agregar descripciones detalladas siempre que sea posible. Pero, sin importar qué tan claro creas que es tu formulario, en algún momento, un usuario cometerá un error.
Cuando un usuario encuentra un error en un formulario, el primer paso es dar a conocer el error. Se debe identificar claramente el campo en el que ocurrió el error, y el error en sí se debe describir al usuario en texto.
Existen diferentes métodos para mostrar mensajes de error, como los siguientes:
- Un modal intercalado cerca de donde se produjo el error
- Una colección de errores agrupados en un mensaje más grande en la parte superior de la página
Asegúrate de prestar atención al foco del teclado y a las opciones de región live de ARIA cuando anuncies errores.
Siempre que sea posible, ofrécele al usuario una sugerencia detallada sobre cómo corregir el error. Hay dos atributos disponibles para notificar a los usuarios sobre errores.
- Puedes usar el atributo HTML required. El navegador proporciona un mensaje de error genérico basado en los parámetros de validación de archivos.
- También puedes usar el atributo aria-required para compartir un mensaje de error personalizado con las TA. Solo las TA reciben este mensaje, a menos que agregues código para que el mensaje sea visible para todos los usuarios.
Una vez que el usuario crea que se resolvieron todos los errores, permítele volver a enviar el formulario y proporcione comentarios sobre los resultados del envío. Un mensaje de error le indica al usuario que debe realizar más actualizaciones, mientras que un mensaje de éxito confirma que resolvió todos los errores y envió el formulario correctamente.
Criterios de éxito adicionales
La WCAG 2.2 introdujo los siguientes criterios de éxito que se enfocan en experiencias de formularios más accesibles: