Los problemas de accesibilidad web más comunes y cómo identificarlos
Un sitio web puede funcionar a la perfección para el equipo que lo gestiona y, aun así, generar serias dificultades para algunos usuarios.
El problema es que muchas barreras de accesibilidad no son evidentes cuando navegas con un ratón, ves la pantalla con claridad y utilizas el sitio web exactamente como se probó internamente.
Cambia un poco la situación.
Intenta completar una compra sin usar el ratón. Usa solo la tecla Tab. Amplía la página al 200 %. Mira un formulario e imagina que las etiquetas de sus campos están siendo leídas por un lector de pantalla.
El sitio web empieza a verse diferente.
Aquí tienes algunos de los problemas que vale la pena revisar primero.
Imágenes sin texto alternativo
Una imagen de producto, un diagrama, un icono o un banner pueden comunicar información a la que un usuario no puede acceder si la imagen no cuenta con una alternativa de texto adecuada.
Las WCAG 2.2 exigen alternativas de texto para el contenido no textual cuando este transmite información o cumple una función. Las imágenes puramente decorativas se tratan de forma distinta y pueden ser ignoradas por las tecnologías de asistencia.
Aquí se comete un error muy común. El equipo comprueba si el alt atributo existe y considera que el problema está resuelto.
La calidad del texto es igual de importante.
Si la imagen muestra un producto, la descripción debe proporcionar información relevante sobre él. Si la imagen es un gráfico, decir simplemente "gráfico" no ayuda al usuario a entender los datos presentados.
Cómo realizar la comprobación
Empieza por las páginas que contengan muchas imágenes. La página de inicio, las páginas de productos, los artículos del blog y las páginas de destino son buenos puntos de partida.
El Wawsome Accessibility Checker puede identificar problemas detectables automáticamente, como la falta de texto alternativo en las imágenes o que este sea inadecuado.
Para las imágenes que ya tienen texto alt , sigue siendo necesaria una revisión humana.
Contraste insuficiente
El texto gris claro sobre un fondo blanco puede parecer sutil en un diseño. Para una persona con baja visión, puede resultar difícil de leer.
El problema suele aparecer en textos secundarios, marcadores de posición, botones, menús y elementos en estados deshabilitados o inactivos.
Las WCAG incluyen criterios para el contraste de texto y para ciertos elementos gráficos y componentes de la interfaz de usuario.
El contraste debe comprobarse en el producto real. Un archivo de diseño puede utilizar los colores correctos, mientras que la implementación final puede acabar con valores diferentes.
Cómo comprobarlo
Prueba los colores para:
- Texto principal y secundario
- Enlaces y botones
- Mensajes de error y notificaciones
- Controles y componentes interactivos
- Estados de interacción (hover) y enfoque (focus)
- Gráficos o información transmitida a través del color
No limites las pruebas a la página de inicio. El proceso de pago y los formularios suelen ser donde un contraste deficiente resulta mucho más costoso para el usuario.
Formularios sin etiquetas ni instrucciones claras
Los formularios aparecen en casi todas partes.
La creación de cuentas, las solicitudes de presupuesto, el pago de facturas, la programación de citas y los procesos de pago utilizan campos donde los usuarios deben introducir información.
Las WCAG exigen etiquetas o instrucciones cuando se requiere la intervención del usuario. El objetivo es garantizar que los usuarios comprendan qué información deben proporcionar.
Un marcador de posición (placeholder) no debe considerarse automáticamente como un sustituto de una etiqueta correctamente implementada.
Luego están los mensajes de error.
"Entrada no válida" no es de mucha ayuda.
Los usuarios necesitan entender qué salió mal y qué deben corregir. En un formulario largo, identificar claramente el campo problemático es aún más importante.
Cómo comprobarlo
Elige un flujo de usuario completo y recórrelo de principio a fin.
Podría ser:
- Formulario de contacto
- Creación de cuenta
- Proceso de pago
- Reserva de citas en línea
- Solicitud de presupuesto
- Iniciar sesión
- Restablecimiento de contraseña
- Pago de facturas
Compruebe que cada campo tenga una etiqueta clara y que los mensajes de error se puedan entender sin depender exclusivamente del color.
En formularios importantes, las pruebas con teclado y lector de pantalla pueden proporcionar información que un escáner no logra captar por completo.
Navegación que no funciona con el teclado
Pruebe un ejercicio sencillo.
Deje el ratón a un lado y presione la tecla Tab.
¿Puedes acceder al menú? ¿Puedes abrir los submenús? ¿Puedes seleccionar un producto? ¿Puedes completar el formulario? ¿Puedes enviarlo?
Las WCAG incluyen requisitos para la accesibilidad mediante teclado y para evitar situaciones en las que el foco quede atrapado dentro de un componente.
El problema suele aparecer en componentes personalizados.
Los menús desplegables, modales, carruseles, selectores de fecha y menús basados en JavaScript pueden funcionar perfectamente con el ratón, pero comportarse de forma deficiente con el teclado.
Cómo realizar la comprobación
Usa la tecla Tab para avanzar y Shift + Tab para retroceder.
Sigue el indicador visual de foco. Siempre deberías poder ver en qué parte de la página te encuentras.
Prueba los componentes interactivos usando las teclas Enter, Espacio y las flechas de dirección cuando el comportamiento del componente lo requiera.
Realiza la prueba en los flujos más importantes para el negocio. El inicio de sesión, el proceso de compra, la reserva de citas y los formularios importantes deben ser los primeros en comprobarse.
Botones y enlaces sin nombres accesibles
El icono de una lupa es visualmente fácil de reconocer como "Buscar".
Para la tecnología de asistencia, el icono necesita la información programática necesaria para que su función pueda comunicarse al usuario.
Las WCAG abordan el nombre, el rol y el valor de los componentes de la interfaz de usuario. Un control sin un nombre accesible puede ser muy difícil de usar con tecnologías de asistencia.
El problema suele aparecer en:
- Botones que solo contienen iconos
- Menús móviles
- Botones de cierre
- Controles de video
- Elementos de carrusel
- Botones para compartir en redes sociales
- Componentes personalizados
- Enlaces con texto vago como "haga clic aquí"
Un nombre accesible debe comunicar el propósito del elemento.
Cómo verificar
Puede comenzar con el Comprobador de accesibilidad Wawsome para problemas detectables automáticamente.
Para componentes importantes, utiliza también el inspector de accesibilidad de tu navegador o prueba la página con un lector de pantalla.
Si el usuario escucha "botón" sin saber qué hace ese botón, la implementación debe revisarse.
Estructura de encabezados incorrecta
A veces, los encabezados se utilizan únicamente por su apariencia visual.
Un texto recibe una etiqueta H2 porque el tamaño parece adecuado. Otro se convierte en H4 porque encaja en el diseño. Con el tiempo, la estructura semántica se pierde.
Para los usuarios de lectores de pantalla, los encabezados pueden ser una forma eficaz de navegar por una página.
Una página larga que contiene artículos, términos legales, servicios o productos resulta mucho más fácil de navegar cuando su estructura de encabezados es lógica.
Cómo comprobarlo
Observa el esquema de la página.
El encabezado principal debe indicar claramente el tema. Las secciones importantes deben organizarse en una jerarquía lógica.
No elija un nivel de encabezado basándose en el tamaño visual que desea. La apariencia visual puede controlarse con CSS. La semántica debe describir la estructura del contenido.
Documentos y archivos descargables
Un sitio web puede tener páginas bien estructuradas y aun así ofrecer un PDF inaccesible justo cuando el usuario llega a la información que necesita.
Esto es común en el sector público, la banca, los seguros, la educación y la atención sanitaria.
Los documentos pueden contener:
- Imágenes escaneadas sin texto disponible
- Estructura incorrecta
- Formularios PDF difíciles de completar
- Gráficos sin alternativas
- Orden de lectura incorrecto
- Enlaces mal descritos
- Tablas difíciles de interpretar
Si un documento forma parte del servicio prestado al usuario, se debe evaluar su accesibilidad.
Contenido de vídeo sin subtítulos
El vídeo se utiliza cada vez más para presentaciones de productos, tutoriales, contenido educativo y comunicación en redes sociales.
Si la información se comunica mediante voz, los usuarios que no pueden oír el contenido necesitan una alternativa adecuada.
Los subtítulos deben reflejar con precisión la información hablada. La transcripción automática puede ayudar en la producción, pero el resultado debe revisarse antes de su publicación.
Si un vídeo contiene información importante exclusivamente a través de contenido visual, también puede ser necesaria una descripción adecuada de dicha información visual.
¿Por qué un escáner no detecta todo?
El escaneo automatizado es extremadamente útil. Para sitios web grandes, puede ahorrar mucho tiempo y sacar a la luz problemas recurrentes.
El Comprobador de accesibilidad Wawsome puede identificar muchos problemas de las WCAG detectables automáticamente, como la falta de texto alternativo, fallos de contraste, etiquetas de formulario ausentes, estructuras de encabezados incorrectas y ciertos problemas con el teclado o elementos interactivos.
Una herramienta puede detectar que un alt existe el atributo.
No puede determinar con certeza si ese texto realmente explica la imagen en el contexto de la página.
Puede detectar ciertos problemas estructurales.
No puede reproducir completamente la experiencia de un usuario que intenta completar un proceso complejo con un lector de pantalla.
Por eso, una evaluación de accesibilidad útil combina varios tipos de análisis.
Empieza por los flujos importantes
Si tu sitio web tiene 5000 páginas, revisar manualmente cada elemento puede volverse difícil de gestionar rápidamente.
Comienza por los recorridos esenciales del usuario.
En el caso del comercio electrónico, revisa la página de producto, el carrito y el proceso de pago.
En el caso de la banca, revisa el inicio de sesión, las transacciones y los servicios principales que utilizan los clientes.
En el sector sanitario, céntrese en la reserva de citas, los formularios, la cuenta del paciente y el acceso a la información.
En el sector público, revise la presentación de documentos, los formularios, los pagos y el acceso a la información que necesitan los ciudadanos.
A continuación, amplíe la evaluación al resto del sitio web.
El impacto en el usuario debe determinar el orden en que se solucionan los problemas.
¿Cómo puede ayudar la monitorización?
Supongamos que ha completado una evaluación y el equipo ha corregido los problemas prioritarios.
Dos semanas después, se publica una nueva página de destino. Marketing sube nuevas imágenes. Desarrollo cambia el formulario principal. Se añaden otros 50 productos.
El sitio web ha cambiado.
El Wawsome Accessibility Monitor puede monitorizar su sitio web de forma continua y volver a analizar las páginas cuando se detectan actualizaciones, lo que ayuda a identificar problemas detectables introducidos por nuevos contenidos o componentes.
Para un sitio web que se actualiza con frecuencia, las comprobaciones de accesibilidad deben formar parte del proceso habitual de gestión del sitio.
¿Qué haces con los problemas que encuentras?
Un informe extenso puede dar la impresión de que todos los problemas deben solucionarse en el mismo orden.
En la práctica, establecer prioridades ayuda.
A veces olvidamos hacer una pregunta sencilla: ¿qué impide que el usuario complete su tarea?
Un problema en el proceso de pago merece atención inmediata si impide que un cliente finalice su pedido.
Un botón inaccesible en un flujo de citas puede impedir que un paciente seleccione una fecha.
Un problema de autenticación puede hacer que toda una cuenta sea inutilizable para un usuario en particular.
Después de evaluar el impacto, puedes analizar la frecuencia con la que ocurre el problema y cuántas páginas se ven afectadas.
Aquí es donde el informe empieza a ser útil para el equipo de desarrollo. Los problemas se convierten en tareas concretas que pueden incluirse en los sprints de corrección.
Cómo puede ayudar Wawsome
Si aún no has evaluado tu sitio web, un análisis inicial es un primer paso práctico.
El Comprobador de Accesibilidad de Wawsome puede identificar problemas detectables automáticamente y ofrecer una imagen inicial de las áreas que requieren atención.
Tras el análisis, los resultados pueden complementarse con comprobaciones manuales para los criterios que requieren evaluación humana.
Los sitios web que cambian con frecuencia pueden utilizar el Monitor de Accesibilidad de Wawsome para realizar un seguimiento de los problemas que surjan posteriormente.
Para las funciones que se ofrecen directamente a los usuarios, también puedes explorar el Widget de Accesibilidad de Wawsome.
También puedes explorar la gama completa de funciones de accesibilidad de Wawsome.
Preguntas frecuentes
¿Cómo puedo comprobar si mi sitio web tiene problemas de accesibilidad?
Puedes empezar con un escáner automatizado para detectar problemas que se puedan identificar mediante programación. Continúa con pruebas manuales de los flujos de usuario importantes y, cuando sea necesario, realiza pruebas con teclado o tecnologías de asistencia.
¿Puede una puntuación indicarme si mi sitio web es accesible?
Una puntuación ofrece una visión general de los criterios evaluados por la herramienta. Las herramientas automatizadas no pueden determinar por sí solas la accesibilidad completa de un sitio web.
¿Qué problemas de accesibilidad puedo identificar yo mismo sin conocimientos técnicos?
Puedes realizar algunas comprobaciones sencillas. Intenta navegar con el teclado, amplía la página, comprueba si los formularios tienen etiquetas claras y revisa el contraste del texto. Para los criterios técnicos, necesitarás las herramientas adecuadas y personas familiarizadas con las WCAG.
¿Por qué debo volver a comprobar mi sitio web después de aplicar las correcciones?
Los sitios web cambian. Una nueva página de destino, un formulario o un componente pueden introducir nuevas barreras. Es útil realizar un seguimiento y volver a probar tras realizar cambios relevantes.
¿Cómo debo priorizar los problemas que encuentro?
Empieza por las barreras que impiden a los usuarios completar acciones importantes. Los procesos de pago, la autenticación, las citas, los formularios y los pagos pueden tener un impacto directo en los usuarios. Después, puedes organizar los problemas restantes según su gravedad y su frecuencia de aparición en el sitio web.
Un buen punto de partida
La accesibilidad es mucho más fácil de gestionar cuando puedes ver los problemas concretos que afectan a tu propio sitio web.
Analiza las páginas importantes, comprueba los flujos que los usuarios deben poder completar y determina qué barreras deben abordarse primero.
Un escáner ayuda a identificar los problemas detectables automáticamente. Las pruebas manuales completan el panorama cuando se requiere contexto y evaluación humana.
A partir de ahí, ya tendrás algo útil para el equipo: problemas reales, páginas afectadas y un punto de partida claro para la corrección.