Los problemas de accesibilidad más comunes en los sitios web

Introducción

A menudo se piensa que los problemas de accesibilidad son el resultado de una complejidad técnica inusual: aplicaciones avanzadas, tecnologías de asistencia poco conocidas o interacciones altamente especializadas que solo comprende un pequeño grupo de expertos.

En la práctica, muchas de las barreras que se repiten en los sitios web son mucho más comunes.

Un botón no tiene suficiente contraste. Una imagen informativa no tiene un texto alternativo útil. Un encabezado parece correcto visualmente, pero no está marcado como encabezado. Un formulario funciona con ratón, pero se vuelve confuso con un lector de pantalla. Se abre un modal, pero el foco del teclado permanece en algún punto detrás de él.

Ninguno de estos patrones es extraordinario. Aparecen en interfaces cotidianas porque los sitios web reutilizan una y otra vez los mismos bloques básicos.

Esa repetición es precisamente lo que hace que los problemas de accesibilidad sean especialmente importantes. Una mala decisión en un componente compartido, un token de diseño, una plantilla o un patrón de contenido puede propagarse silenciosamente por decenas o cientos de páginas.

El objetivo de este artículo no es ofrecer otra checklist que anime a los equipos a corregir defectos aislados uno por uno. Es analizar algunos de los problemas más comunes de accesibilidad web, cómo afectan a las personas, por qué aparecen con tanta frecuencia y qué pueden revelar sobre los sistemas que hay detrás de un sitio web.

Si estás comenzando con accesibilidad, nuestra introducción a la accesibilidad web explica la base general. Si quieres entender el estándar que está detrás de muchos de los requisitos que veremos aquí, consulta WCAG explicado sin jerga técnica.

Contraste de color insuficiente

El bajo contraste es uno de los problemas de accesibilidad más conocidos, pero también uno de los más fáciles de subestimar.

El problema no se limita a texto gris claro sobre fondo blanco. El contraste afecta al texto, los iconos, los controles de formularios, los indicadores de foco, los estados y otros elementos visuales que las personas necesitan distinguir para comprender u operar una interfaz.

Un diseño puede verse elegante en un monitor calibrado y en condiciones controladas, y aun así resultar difícil de leer para una persona con baja visión, menor sensibilidad al contraste o simplemente para alguien que utiliza una pantalla bajo luz intensa.

Los problemas también aparecen cuando se coloca texto sobre fotografías, degradados o vídeo. Una combinación que funciona en una zona de una imagen puede volverse ilegible en otra.

El problema más profundo suele ser sistémico. Si una combinación de colores con poco contraste se define en un token de diseño y después se reutiliza para textos secundarios, botones, metadatos o estados deshabilitados, la misma barrera puede aparecer en todo el producto.

Por eso, el contraste no debería tratarse como un ajuste visual de última hora. Debe formar parte del sistema de diseño y comprobarse en los contextos reales en los que se utilizarán esos colores.

Texto alternativo ausente o incorrecto

Las imágenes necesitan un tratamiento diferente según la función que cumplen.

Una imagen informativa puede necesitar texto alternativo porque comunica información que, de otro modo, no estaría disponible para alguien que no puede verla. Una imagen decorativa puede necesitar un atributo alt vacío para que las tecnologías de asistencia la ignoren. Una imagen funcional, como un icono utilizado como control, necesita un nombre accesible que comunique la acción.

El error habitual es tratar el texto alternativo como una casilla que simplemente hay que rellenar.

Eso puede generar descripciones que técnicamente existen, pero que no ayudan a nadie. Un alt como “image123.jpg” no sirve. Una descripción que enumera todos los objetos visibles puede resultar igual de inútil si la función de la imagen es mucho más sencilla. Por otro lado, dejar el alt vacío en una imagen que comunica información esencial elimina esa información por completo para algunos usuarios.

Un buen texto alternativo depende del propósito y del contexto, no únicamente de la apariencia visual.

Una pregunta útil es: si la imagen no estuviera disponible, ¿qué información necesitaría una persona para comprender el mismo punto o completar la misma tarea?

Jerarquía de encabezados incorrecta

Los encabezados hacen mucho más que aumentar el tamaño del texto.

Comunican la estructura de una página. Las personas recorren visualmente los encabezados para entender cómo está organizado el contenido, y muchos usuarios de lectores de pantalla navegan directamente entre encabezados para moverse con eficiencia por páginas largas.

Los problemas aparecen cuando los niveles de encabezado se eligen por su tamaño visual en lugar de por su estructura semántica, cuando un texto que parece un encabezado está implementado como un párrafo normal o cuando la jerarquía salta entre niveles sin reflejar la relación entre las secciones.

Por eso, una página puede parecer perfectamente organizada y tener al mismo tiempo una estructura subyacente confusa.

El objetivo no es seguir una regla mecánica según la cual cada página deba utilizar todos los niveles de encabezado en orden. Lo importante es que los encabezados representen la estructura del contenido y describan las secciones que introducen.

Esta es una de las razones por las que accesibilidad y diseño de contenidos están tan relacionados. Una buena estructura ayuda tanto a quienes utilizan tecnologías de asistencia como a cualquier persona que intenta recorrer rápidamente una página compleja.

Formularios inaccesibles

Los formularios concentran muchos problemas de accesibilidad en una pequeña cantidad de interfaz.

Un formulario puede mostrar etiquetas visibles pero no asociarlas correctamente con los campos que describen. Los campos obligatorios pueden comunicarse únicamente mediante color. Las instrucciones pueden aparecer demasiado tarde. Los mensajes de error pueden ser difíciles de localizar o no explicar cómo corregir el problema.

Una persona también puede encontrarse con controles técnicamente accesibles, pero dispuestos en una secuencia innecesariamente confusa.

La guía de formularios de W3C hace énfasis en etiquetas claras, instrucciones, agrupación y feedback porque los formularios son complejos tanto visual como cognitivamente. Las etiquetas asociadas correctamente también permiten que las tecnologías de asistencia identifiquen con precisión la función de los controles.

La forma más útil de evaluar un formulario no es preguntarse únicamente si todos los campos aparecen en el árbol de accesibilidad. Hay que preguntarse si una persona puede comprender qué información se requiere, introducirla mediante su método de interacción preferido, reconocer cuándo algo ha salido mal y recuperarse del error sin perder su progreso.

Un formulario es un proceso, no una colección de campos.

Foco de teclado no visible

La accesibilidad mediante teclado y el foco visible están relacionados, pero no son lo mismo.

Un elemento puede recibir técnicamente el foco del teclado y, aun así, ofrecer muy poca indicación visual de dónde se encuentra ese foco.

Esto ocurre con frecuencia cuando el CSS de un sitio elimina el outline predeterminado del navegador para conseguir un estilo visual más limpio, pero no lo sustituye por una alternativa igualmente visible.

Para alguien que navega con Tab, eso convierte una página operable en un ejercicio de adivinación.

El foco visible debe dejar clara la posición actual. También debe seguir siendo perceptible sobre distintos fondos, componentes y estados.

La solución no consiste necesariamente en conservar exactamente todos los estilos predeterminados del navegador. Los indicadores de foco pueden diseñarse para integrarse en el lenguaje visual del producto. Pero eliminarlos sin ofrecer un reemplazo sólido suprime información de la que dependen los usuarios de teclado.

Trampas de teclado

Una trampa de teclado ocurre cuando una persona puede llevar el foco hacia una parte de la interfaz, pero no puede salir de ella utilizando el teclado.

Puede suceder en modales, menús, widgets embebidos, controles personalizados o componentes con un comportamiento JavaScript mal gestionado.

El impacto puede ser grave. Una persona que utiliza ratón puede simplemente hacer clic en otro lugar. Una persona que utiliza teclado puede quedar, en la práctica, atrapada dentro del componente.

Algunas interfaces sí necesitan contener temporalmente el foco. Un diálogo modal, por ejemplo, normalmente mantiene la interacción del teclado dentro del propio diálogo mientras está abierto. Eso no es lo mismo que una trampa, porque la persona debe seguir pudiendo alcanzar todos los controles relevantes, cerrar el diálogo y volver a un punto lógico de la página subyacente.

La diferencia está en si la interacción está gestionada de forma intencional o si la persona ha perdido el control.

Las barreras de accesibilidad suelen aparecer dentro de patrones de interfaz cotidianos que, por lo demás, parecen pulidos y completos.

Enlaces ambiguos

Los enlaces deberían ayudar a las personas a entender adónde van.

Textos como “haz clic aquí”, “leer más” o “saber más” pueden tener sentido cuando alguien lee todo el párrafo que los rodea. Pero las personas no siempre encuentran los enlaces dentro de ese contexto.

Los usuarios de lectores de pantalla pueden navegar directamente entre enlaces. Las personas que recorren visualmente una página también pueden saltar de un enlace a otro sin leer cada frase que los rodea.

Si varios enlaces dicen exactamente “Saber más”, resulta mucho más difícil anticipar qué destino abre cada uno.

Un buen texto de enlace no necesita ser largo. Necesita comunicar suficiente información para que el destino o la acción resulten comprensibles.

Esto también es una cuestión de calidad de contenido. Los enlaces específicos reducen la incertidumbre para todos.

Semántica incorrecta de botones

Los botones y los enlaces pueden verse casi idénticos dentro de un sistema de diseño, pero tienen funciones diferentes.

Un enlace normalmente lleva a la persona a otro lugar.

Un botón ejecuta una acción.

Los problemas aparecen cuando el estilo visual pasa a ser más importante que el comportamiento semántico: un div clicable se diseña para parecer un botón, se utiliza un enlace para ejecutar una acción o se construye un componente personalizado sin reproducir el comportamiento de teclado y accesibilidad que las personas esperan de un control nativo.

Para una persona que utiliza ratón, la interfaz puede seguir pareciendo funcional.

Para quienes utilizan teclado o tecnologías de asistencia, el elemento puede no anunciarse correctamente, no recibir foco o responder a una interacción distinta de la esperada.

Los elementos HTML nativos ya aportan una cantidad importante de comportamiento esperado. Los componentes personalizados pueden ser accesibles, pero requieren que los equipos comprendan y reproduzcan deliberadamente esas expectativas.

Modales inaccesibles

Los modales no son inaccesibles por naturaleza.

Los problemas suelen estar en cómo se implementan.

Cuando se abre un modal, el foco del teclado debería desplazarse a un punto significativo dentro de él. La persona debería poder recorrer sus controles en un orden lógico, entender que se ha abierto un diálogo y cerrarlo mediante métodos de interacción esperados.

Mientras el modal está activo, el foco no debería desplazarse hacia contenido no relacionado que se encuentra detrás. Cuando el modal se cierra, normalmente el foco debería regresar a un lugar lógico, con frecuencia al control que lo abrió.

Si alguno de estos detalles falla, la experiencia puede volverse confusa.

Un usuario visual percibe inmediatamente el modal porque la pantalla cambia. Un usuario de lector de pantalla o teclado necesita señales estructurales y de interacción equivalentes.

Este es un buen ejemplo de por qué la accesibilidad no puede evaluarse únicamente a partir de capturas de pantalla. La barrera existe en el comportamiento a lo largo del tiempo.

Etiquetas e instrucciones ausentes

No todos los controles se explican por sí solos visualmente.

Los botones que solo contienen iconos, filtros, controles de búsqueda, selectores, campos de fecha, cargas de archivos y componentes personalizados poco familiares suelen depender mucho del contexto.

Si ese contexto no está disponible de forma programática, los usuarios de tecnologías de asistencia pueden encontrar un control sin un nombre o propósito comprensible.

Los formularios presentan un problema relacionado cuando se utiliza placeholder en lugar de una etiqueta persistente. En cuanto la persona comienza a escribir, la instrucción puede desaparecer. Además, el texto placeholder puede ser visualmente sutil y no es un sustituto fiable de una etiqueta adecuada.

W3C recomienda que los controles tengan etiquetas que describan su propósito y que las personas reciban instrucciones cuando sean necesarias para completar correctamente un formulario.

No se trata de añadir más texto en todas partes. Se trata de garantizar que la interfaz proporcione suficiente información en el momento en que alguien la necesita.

Uso incorrecto de ARIA

ARIA — Accessible Rich Internet Applications — proporciona semántica que puede ayudar a las tecnologías de asistencia a comprender componentes personalizados y estados dinámicos de la interfaz.

Es extremadamente útil cuando HTML nativo no puede expresar lo que necesita un componente.

También es fácil utilizarlo mal.

Un rol incorrecto puede indicar a una tecnología de asistencia que un elemento se comporta de una forma distinta a la real. Un estado ARIA puede declararse una vez y después no actualizarse cuando cambia la interfaz. Un nombre accesible puede entrar en conflicto con el texto visible. Puede añadirse ARIA innecesariamente a elementos nativos que ya proporcionan la semántica correcta.

La especificación WAI-ARIA anima expresamente a utilizar la semántica nativa del lenguaje siempre que sea posible.

El principio práctico es sencillo: utiliza HTML nativo cuando ya proporciona la semántica y el comportamiento que necesitas. Utiliza ARIA cuando aporte información realmente necesaria y asegúrate de que el comportamiento resultante coincida con lo que ARIA comunica.

Más metadatos de accesibilidad no significan automáticamente más accesibilidad.

Problemas de zoom y responsive

Un sitio responsive puede funcionar perfectamente en los breakpoints móviles habituales y, aun así, fallar cuando una persona amplía la página o aumenta el tamaño del texto.

El contenido puede quedar recortado. La navegación puede desaparecer. Los encabezados fijos pueden ocupar gran parte del viewport. Los diálogos pueden extenderse más allá del área visible. Los controles pueden superponerse y puede aparecer desplazamiento horizontal donde hace que la página sea difícil de utilizar.

Estos problemas importan especialmente para las personas con baja visión que amplían el contenido para poder leerlo cómodamente.

La distinción clave está entre adaptarse a un dispositivo y adaptarse a las necesidades de presentación de la persona.

El diseño responsive debería preservar el significado y la funcionalidad a medida que cambia el espacio disponible. Eso incluye cambios provocados por el zoom del navegador, el aumento del tamaño del texto, la orientación y otros ajustes del usuario, no únicamente el ancho de la pantalla de un teléfono.

Por eso, las pruebas de accesibilidad deben incluir algo más que unos pocos tamaños de viewport predefinidos.

Por qué las pruebas automatizadas no detectan todo

Las herramientas automatizadas de accesibilidad son valiosas.

Pueden analizar grandes cantidades de páginas, identificar de forma consistente determinados problemas a nivel de código y detectar cuestiones que de otro modo serían fáciles de pasar por alto. Utilizadas durante el diseño y el desarrollo, pueden ayudar a los equipos a encontrar problemas antes de que lleguen a producción.

Pero las herramientas automatizadas no pueden evaluar toda la experiencia.

La guía de W3C sobre herramientas de evaluación de accesibilidad deja clara esta limitación: algunas comprobaciones no pueden automatizarse y requieren criterio humano. Las herramientas pueden ayudar en la evaluación de accesibilidad, pero no pueden determinar por sí solas si algo es accesible.

Un escáner puede identificar una imagen sin texto alternativo. Tiene muchas más dificultades para decidir si un texto alternativo existente comunica realmente el propósito de la imagen.

Puede detectar algunos fallos de contraste. No puede determinar de forma fiable si un proceso de varios pasos tiene sentido.

Puede identificar determinados errores semánticos. No puede experimentar un orden de foco confuso de la misma forma que una persona que navega mediante teclado.

Puede confirmar que un botón tiene un nombre accesible. No siempre puede determinar si ese nombre resulta útil dentro del contexto que lo rodea.

Esta diferencia importa porque las puntuaciones automatizadas pueden generar una falsa sensación de seguridad. Una página con una puntuación alta puede seguir conteniendo barreras graves que solo aparecen mediante interacción manual.

Por eso, una revisión de accesibilidad significativa combina automatización con pruebas manuales, navegación por teclado, comprobaciones de zoom y reflow, pruebas con tecnologías de asistencia, revisión de contenido y, cuando sea posible, investigación con personas con discapacidad.

Las herramientas automatizadas pueden identificar problemas importantes de accesibilidad, pero no pueden evaluar toda la experiencia humana.

Corrige el patrón, no solo la página

Uno de los momentos más útiles de una revisión de accesibilidad suele llegar después de documentar varios problemas individuales.

Empiezan a aparecer patrones.

El mismo botón con poco contraste existe en veinte páginas.

Todos los formularios utilizan el mismo componente de error que no comunica correctamente los problemas.

Varios modales heredan el mismo problema de gestión del foco.

Todas las tarjetas contienen el mismo enlace ambiguo de “Saber más”.

En ese punto, el sitio web ya no tiene realmente veinte fallos de botones sin relación entre sí ni diez fallos distintos de modales. Tiene un patrón compartido que está produciendo repetidamente la misma barrera.

Corregir páginas individuales puede eliminar casos visibles del problema, pero no necesariamente evita que vuelva a aparecer.

La solución más sólida suele ser identificar el origen.

Ese origen puede ser:

• un token de diseño;
• un componente reutilizable;
• una plantilla del CMS;
• una regla editorial;
• una convención de desarrollo;
• una integración de terceros;
• o una carencia en el proceso de revisión del equipo.

Por eso, las auditorías de accesibilidad son más útiles cuando hacen algo más que producir una lista de defectos. Los hallazgos individuales importan, pero los equipos también necesitan entender cuáles comparten la misma causa subyacente.

Cuando una decisión tipográfica inaccesible se integra en un patrón compartido, la misma barrera puede propagarse a todas las interfaces que lo reutilizan.

Un sistema de diseño puede hacer que esta relación sea especialmente visible. Los componentes y tokens compartidos multiplican decisiones a lo largo de un producto. Si esas decisiones son accesibles, el sistema puede ayudar a escalar buenos patrones. Si contienen barreras, esas barreras también escalan.

Esta es también la razón por la que la accesibilidad debería formar parte del diseño web desde el primer día. Prevenir un problema en el componente o patrón suele ser más sostenible que localizar cada instancia una vez que el producto ha crecido.

Encontrar problemas individuales de accesibilidad es útil. Comprender por qué siguen apareciendo es más valioso.

Una revisión completa de accesibilidad debería identificar ambas cosas: las barreras que encuentran las personas y los componentes, patrones y procesos que las están produciendo.

Así es como el trabajo de accesibilidad pasa de reparar páginas repetidamente a mejorar el sistema que las crea.