El formulario que creas es para personas. Las personas usan distintos dispositivos. Algunas usan mouse, otras táctiles, teclados, otros, un dispositivo controlado con movimientos oculares. Algunos usan un lector de pantalla; otros, una pantalla pequeña; otros, software para ampliar texto. Todos quieren usar tu formulario. Aprende a hacer que tu formulario sea accesible y fácil de usar para todos.
Asegúrate de que los usuarios comprendan el propósito de un campo de formulario
Existen muchos controles de formularios que puede elegir.
¿Qué tienen en común?
Cada control de formulario debe tener un elemento <label> asociado.
El elemento <label> describe el propósito de un control de formulario.
El texto <label> está asociado visualmente con el control de formulario y los lectores de pantalla lo leerán en voz alta.
Además, si presionas el <label> o haces clic en él, se enfoca el control del formulario asociado,
lo que lo convierte en un objetivo más grande.
Usa HTML significativo para acceder a las funciones integradas del navegador
En teoría, podrías compilar un formulario usando solo elementos <div>.
Incluso puedes hacer que parezca una <form> nativa.
¿Cuál es el problema al usar
elementos no semánticos?
Los elementos del formulario integrados ofrecen muchas funciones integradas. Veamos un ejemplo.
Visualmente, <input> (el primero del ejemplo) y <div> se ven iguales.
Incluso puedes insertar texto en ambos, ya que <div> tiene un
contenteditable.
Sin embargo, existen muchas diferencias entre usar un elemento <input> apropiado y un <div>
que se asemeja a un <input>.
Un usuario de lector de pantalla no reconoce <div> como elemento de entrada.
y no puede completar el formulario.
Todo lo que el usuario escucha del lector de pantalla es "Nombre",
sin indicación de que el elemento es un control de formulario para agregar texto.
Hacer clic en <div>Name</div> no enfoca el <div> que lo acompaña, mientras que <label> y
<input> se conectan mediante los atributos for y id.
Después de enviar el formulario, los datos ingresados en el <div> no se incluyen en la solicitud.
Si bien es posible adjuntar los datos con JavaScript,
un objeto <input> lo hace de forma predeterminada.
Los elementos integrados del formulario tienen otras funciones.
Por ejemplo, con los elementos de formulario adecuados y las inputmode o type correctas,
un teclado en pantalla muestra los caracteres apropiados. Usa el atributo inputmode en un <div>
no puede hacerlo.
Garantizar que los usuarios conozcan el formato de datos esperado
Puedes definir varias reglas de validación para un control de formulario.
Por ejemplo, supongamos que un campo de formulario siempre debe tener al menos ocho caracteres.
Usa el atributo minlength para indicar la regla de validación a los navegadores.
¿Cómo puedes asegurarte de que los usuarios también conozcan la regla de validación? Díselo.
Agregue información sobre el formato esperado directamente debajo del control de formularios.
Para que sea más claro
para los dispositivos de asistencia,
Usa el atributo aria-describedby en el control de formulario.
y una id en el mensaje de error con el mismo valor para conectar ambos.
Ayudar a los usuarios a encontrar el mensaje de error de un control de formularios
En un módulo anterior sobre validación, Aprendiste a mostrar mensajes de error en caso de entradas de datos no válidas.
<label for="name">Name</label>
<input type="text" name="name" id="name" required>
Por ejemplo, si un campo tiene un atributo required e ingresan datos no válidos, el navegador mostrará
un mensaje de error junto al control de formulario cuando se envía. Los lectores de pantalla también anuncian el mensaje de error.
También puedes definir tu propio mensaje de error:
En este ejemplo, se necesitan más cambios para conectar el mensaje de error al control del formulario.
Un enfoque simple consiste en usar aria-describedby
en el control de formulario que coincida con id en el elemento del mensaje de error.
Luego, usa aria-live="assertive" para el mensaje de error.
Las regiones en vivo de ARIA anuncian un error a los usuarios de lectores de pantalla en el momento en que se muestra.
El problema de este enfoque
para los formularios con varios campos
es que, por lo general, aria-live solo anunciará el primer error cuando haya varios.
Como se explica en este artículo sobre varios anuncios de aria-live en la misma acción, puedes crear un solo mensaje concatenando todos los errores. Otro enfoque sería anunciar que hay errores y, luego, anunciar errores individuales cuando el campo esté enfocado.
Asegúrate de que los usuarios reconozcan los errores
A veces, los diseñadores colorean el estado no válido de rojo,
con la seudoclase :invalid.
Sin embargo, para comunicar un error o éxito,
nunca debes confiar únicamente en el color.
Para las personas con daltonismo entre rojo y verde,
un borde verde y un rojo se ven casi iguales.
Es imposible ver si el mensaje está relacionado con un error.
Además del color, usa un ícono o prefija los mensajes de error con el tipo de error.
<span class="error">
<strong>Error:</strong>Please use at least eight characters.
</span>
Ayudar a los usuarios a navegar por el formulario
Puedes cambiar el orden visual de los controles de formulario con CSS. Una desconexión entre el orden visual y la navegación con teclado (orden DOM) es un problema para los usuarios de lectores de pantalla y teclados.
Más información para asegurarte el orden visual en la página sigue el orden del DOM.
Ayudar a los usuarios a identificar el control de formulario enfocado actualmente
Usa el teclado para navegar
este formulario.
¿Reconociste que el estilo de los controles del formulario cambió una vez que estaban activos?
Este es el estilo de enfoque predeterminado.
Puedes anularlo con el
Seudoclase :focus de CSS.
Sin importar los estilos que uses en :focus,
Asegúrate siempre de que la diferencia visual entre el estado predeterminado y el de enfoque sea reconocible.
Obtén más información sobre el diseño de indicadores de enfoque.
Asegúrate de que tu formulario se pueda usar
Puedes identificar muchos problemas habituales completando el formulario con diferentes dispositivos. Usa solo el teclado, un lector de pantalla (como NVDA en Windows o VoiceOver en Mac), o acerca la página al 200%. Prueba siempre los formularios en diferentes plataformas en especial los dispositivos o las configuraciones que no usas todos los días. ¿Conoces a alguien que use un lector de pantalla? o alguien que usa un software de ampliación de texto? Pídeles que completen tu formulario. Las revisiones de accesibilidad son geniales; realizar pruebas con usuarios reales es aún mejor.
Obtén más información sobre cómo hacer revisión de accesibilidad y cómo realizar pruebas con usuarios reales.