Jun 25, 2024
Artículo histórico de Make (la fuente indica el 25 de junio de 2024). Este texto reproduce un artículo de invitado publicado por Make en esa fecha. El «yo», las opiniones y los enlaces citados son del autor en esa fecha; no son una afirmación de este sitio ni una garantía de que las referencias sigan vigentes hoy.
En este artículo de invitado de Fillout, Dominic Whyte (cofundador de Fillout) explora cómo puedes mejorar la accesibilidad de tus formularios web.
La concienciación y los esfuerzos en materia de accesibilidad digital han ido ganando impulso de forma constante en los últimos años. En 2021, Forrester Research descubrió que «el 84 % de las empresas están realizando trabajo de [accesibilidad] aunque solo el 36 % de las empresas cuentan con un compromiso desde la dirección para crear experiencias digitales accesibles». Dos años después, los compromisos desde la dirección habían saltado hasta el 60 %.
Hay muchas razones para tener esperanza en que la web se está volviendo más perceptible, comprensible y operable para todo el mundo. Pero como te dirá la mayoría de los expertos, la accesibilidad debe ser un recorrido, no un destino. Sobre todo a medida que la tecnología que todos usamos evoluciona y cambia.
Durante mucho tiempo, todo el mundo se centró en escribir HTML accesible. Luego esos esfuerzos se ampliaron para incluir JavaScript y CSS. Hoy, con toda la comodidad de las plataformas de automatización de arrastrar y soltar, las bases de datos, los constructores de formularios y otras apps SaaS, uno de los mayores retos de accesibilidad es trabajar dentro de los límites del terreno de juego de otra persona. Conseguir que tu app o interfaz sea lo más universalmente usable posible sin controlar el propio código no es fácil.
La mayoría de las apps consolidadas y de buena reputación tienen una base mínima de accesibilidad. Sin embargo, no pueden hacerlo todo por ti. No hay una única forma correcta de optimizar apps e interfaces web para cada grupo demográfico de usuarios. Idealmente, eso sí, las apps te dan ajustes y configuraciones para ofrecer a tus usuarios una experiencia positiva sin importar cómo accedan a la web.
En el caso de los formularios web, a menudo digo a la gente que empiece centrándose en estas cuatro importantes optimizaciones de accesibilidad y que avance desde ahí.
Prueba la navegación con teclado y los tipos de campo problemáticos
Una de las primeras cosas que cualquiera que trabaje en accesibilidad de formularios debería probar es la navegación solo con teclado. Poder interactuar con cada parte de tu formulario sin usar un ratón ni una pantalla táctil mejora drásticamente la experiencia de las personas con discapacidades visuales y motoras. Aunque la mayoría de los constructores de formularios de arrastrar y soltar están optimizados para la navegación con teclado por defecto, no todos los campos de formulario son iguales.
Selectores de fecha
Los selectores de fecha, por ejemplo, son notoriamente difíciles de navegar sin un ratón y no siempre incluyen puntos de referencia que los lectores de pantalla puedan narrar. El experto en accesibilidad Adam Silver, de Form Design Mastery, dice: «Usa un selector de fecha solo cuando los usuarios necesiten encontrar una fecha en relación con otra, o si necesitan saber el día, la semana o el mes al que se refiere la fecha». Para todos los demás casos de uso, Adam sugiere «usar tres cuadros de texto separados para las fechas».
CAPTCHAs
Los CAPTCHA son otro campo de formulario habitual que causa problemas para la navegación con teclado y para los usuarios de lectores de pantalla. Cuando se les pidió calificar los elementos más frustrantes y difíciles de la web, las personas que participaron en la encuesta de WebAIM de 2024 a usuarios de lectores de pantalla señalaron los CAPTCHA como los peores con diferencia.
Y lo que es peor: WebAIM observó que «el orden y la dificultad indicada de los elementos de esta lista se han mantenido prácticamente sin cambios durante los últimos 14 años». Siempre que sea posible, evita los CAPTCHA u opta por otra verificación humana (por ejemplo, un escenario de Make que envíe una contraseña de un solo uso por SMS, o la verificación por email de Fillout).
La lista de opciones de campos de cada app de formularios y su implementación de esos campos son diferentes. Mi recomendación número uno para la accesibilidad de formularios web es hacer siempre una prueba rápida de navegación solo con teclado antes de publicar. Idealmente con un lector de pantalla activado y narrando cada campo al enfocarlo.
Andrew Hedges, de Assistiv Labs, dice: «No hay sustituto para probar con tecnologías de asistencia reales, incluidas las personas que usan estos modos de entrada todos los días. ¿Funciona solo con teclado? ¿Funciona con lectores de pantalla tanto en Windows como en macOS? ¿Funciona con control por voz?»
Empieza experimentando con los lectores de pantalla integrados en Windows (Narrator) y macOS (VoiceOver). Sin embargo, solo alrededor del 10 % de los lectores de pantalla usan esos dos. También deberías probar con NVDA (que es gratuito) y JAWS (que es de pago pero tiene una prueba gratuita), ya que entre los dos acaparan más del 78 % de la cuota de mercado de lectores de pantalla.
Crea mensajes de error que todo el mundo pueda entender
Usar solo el formato de color para comunicar información es un error de accesibilidad habitual en toda la web. Pero es especialmente problemático en los formularios. Cuando un usuario introduce datos que no cumplen los requisitos de un campo, algunos formularios simplemente resaltan en rojo las etiquetas existentes o muestran un icono junto a los envíos problemáticos. Esas notificaciones pueden ser totalmente invisibles para usuarios ciegos o daltónicos.
Según el borrador más reciente del tutorial de formularios de las Pautas de Accesibilidad al Contenido Web (WCAG), un mensaje de error siempre debe estar escrito en texto, especificar qué campo tiene un error, explicar la causa del error (por ejemplo, un campo obligatorio vacío, una respuesta con formato incorrecto, etc.) y proporcionar un ejemplo de envío aceptable.
Para las apps de formularios sin mensajes de error personalizables, una posible solución alternativa es un cuadro de texto condicional que solo aparece cuando un campo anterior no cumple los requisitos de entrada.
Elimina el texto de marcador de posición y las etiquetas flotantes
Sorprendentemente a menudo, las mejoras de accesibilidad requieren eliminar algo pensado para ser útil. Tomemos el texto de marcador de posición, por ejemplo: texto que aparece dentro de un campo vacío con instrucciones o una respuesta de ejemplo. La idea es dar orientación de una forma que ocupa menos espacio en la página. Los expertos sostienen que el texto de marcador de posición hace más daño que bien.
El texto de marcador de posición casi siempre tiene un formato gris de bajo contraste que es difícil de leer para usuarios con baja visión. También desaparece una vez que el campo recibe el foco o se introduce cualquier valor. Cuando un usuario quiere comparar lo que ha escrito con el texto de marcador de posición, debe borrar su respuesta para que el marcador vuelva a ser visible. Si lo usas como lugar para escribir las instrucciones del campo, el espacio es mucho más limitado que en una etiqueta de campo tradicional. Por último, y lo peor desde la perspectiva de la accesibilidad, el texto de marcador de posición suele ser invisible para los lectores de pantalla.
Katie Sherwin escribe para el Nielsen Norman Group que «incluso usando etiquetas, colocar pistas o instrucciones importantes dentro de un campo de formulario puede seguir causando problemas… el texto de marcador de posición es, en general, malo para la accesibilidad». Continúa explicando que una de las alternativas más populares, las etiquetas flotantes, no son mucho mejores.
Las etiquetas flotantes son texto que aparece dentro de los campos de formulario hasta que el campo recibe el foco o el usuario introduce un valor, momento en el que la etiqueta cambia de tamaño y ubicación para «flotar» sobre el campo vacío. La etiqueta nunca desaparece, no usa un color de fuente de bajo contraste y ocupa menos espacio en la página que una etiqueta de campo estática y un campo vacío.
Pero, como señala Sherwin, «los campos con texto son menos perceptibles, y los usuarios pueden pensar que ya hay un valor predeterminado introducido en el campo», una elección de UX cuestionable que se ve agravada por el problema de que las etiquetas flotantes están marcadas de formas que los usuarios de lectores de pantalla ignoran.
El consejo del Nielsen Norman Group aquí es simple: «En lugar de arriesgarte a que los usuarios tropiecen al rellenar formularios o pierdan un tiempo valioso averiguando cómo funcionan, la mejor solución es tener etiquetas claras y visibles colocadas fuera de los campos de formulario vacíos».
Divide los formularios en varias páginas de una sola columna
La mayoría de los usuarios de lectores de pantalla se han acostumbrado tanto a las páginas largas y con muchas palabras que lo primero que hacen es leer todos los encabezados antes de leer los párrafos completos que les interesan. Para esos usuarios (y para todos los demás, sinceramente), las páginas cortas con solo unos pocos campos relacionados son un respiro bienvenido.
Las WCAG dedican una sección entera a los formularios de varias páginas, diciendo: «Siempre que sea posible, divide los formularios largos en varios formularios más pequeños que constituyan una serie de pasos o etapas lógicas. Esto ayuda a que los formularios largos sean menos intimidantes y más fáciles de entender, en particular para personas con menos experiencia usando ordenadores o con diversas discapacidades cognitivas».
Este enfoque también facilita que los usuarios encuentren y corrijan errores de entrada, a la vez que ofrece una alternativa a los diseños de varias columnas «que ahorran espacio» (que perjudican sistemáticamente las tasas de conversión). Además, están las oportunidades añadidas de la lógica de ramificación, que ayuda a los usuarios de lectores de pantalla a saltarse páginas y campos innecesarios según respuestas anteriores.
Cuando los usuarios hayan completado todas las páginas, es fundamental que les proporciones una confirmación de su envío, idealmente junto con una forma de actualizar cualquiera de sus respuestas.
El sistema de diseño de Gov.uk creó el patrón «Check Answers Page» para «aumentar la confianza de los usuarios, ya que pueden ver claramente que han completado todas las secciones y que sus datos han sido capturados» y «reducir las tasas de error, ya que los usuarios tienen una segunda oportunidad de detectar y corregir errores antes de enviar los datos».
Si usas una app de formularios que no puede recrear la Check Answers Page, un simple escenario de Make te ayudaría a enviar por email a los usuarios los recibos de su confirmación y a proporcionar un enlace a otro formulario por si ven algo que necesite cambiarse.
Piensa en la accesibilidad en cada punto donde interactúas con los usuarios
Algunas de las mejoras que puedes hacer en tus formularios también son aplicables a experiencias web no interactivas. Deberías pasar tu logo, los diseños de tus landing pages y tus formularios por un comprobador de contraste antes de publicarlos. Cualquier imagen de tu sitio web o de tus publicaciones en redes sociales debería tener texto alternativo descriptivo. Los vídeos y el audio siempre deben tener subtítulos conformes con WCAG. Los textos siempre deben ser fáciles de entender y consistentes. Hacer tus formularios más accesibles lleva tiempo. Empieza poco a poco. Acostúmbrate a la navegación con teclado, a usar un lector de pantalla, a corregir mensajes de error, marcadores de posición y formularios largos de una sola página. Si consigues dominar eso, estás haciendo que tus experiencias (y la web en general) sean más fáciles de usar para millones de personas en línea.