Accesibilidad web (ADA/WCAG): guía para empresas

La accesibilidad web consiste en diseñar y desarrollar sitios web para que las personas con discapacidad puedan percibirlos, entenderlos, navegar por ellos e interactuar con ellos de forma efectiva. Esto incluye a personas ciegas o con baja visión, personas sordas o con dificultades auditivas, usuarios con discapacidad motriz que no pueden usar un ratón y personas con discapacidad cognitiva que afecta a la comprensión lectora o a la atención. En todo el mundo, más de mil millones de personas, en torno al 16% de la población mundial, viven con algún tipo de discapacidad, lo que convierte la accesibilidad en una cuestión de llegar a un público significativo y a menudo desatendido.

La accesibilidad no es un complemento ni algo que se deja para el final. Es una cualidad fundamental del software bien hecho, al mismo nivel que la seguridad, el rendimiento y la usabilidad. Cuando un sitio web es accesible, funciona mejor para todos, y no solo para las personas con discapacidades permanentes. Los subtítulos ayudan a quien ve un vídeo en un entorno ruidoso. El texto con alto contraste se lee mejor en un teléfono a plena luz del sol. La navegación por teclado beneficia a los usuarios avanzados que prefieren no usar el ratón. Las mejoras de accesibilidad tienen un efecto en cascada que eleva la calidad de toda la experiencia.

En GRADAX integramos la accesibilidad en cada proyecto de diseño web desde la fase de wireframing, no como una tarea de corrección posterior al lanzamiento. Adaptar la accesibilidad en un sitio existente cuesta entre tres y diez veces más que integrarla desde el principio, y los resultados rara vez son tan fluidos. Empezar accesible es el único enfoque que tiene sentido tanto ético como financiero.

En Estados Unidos, los tribunales han interpretado que la Americans with Disabilities Act (ADA) se aplica a los sitios web, en particular a las empresas que prestan servicios al público. El Departamento de Justicia publicó una norma definitiva en abril de 2024 que exige que los sitios web de los gobiernos estatales y locales cumplan con WCAG 2.1 nivel AA, y los tribunales federales han sostenido de forma constante que las empresas privadas con un sitio web de cara al público están sujetas a obligaciones similares. Las demandas por la ADA contra sitios web inaccesibles han crecido más de un 300 % desde 2018, con acuerdos y sentencias que superan habitualmente los 50.000 $.

En Europa, la Ley Europea de Accesibilidad (EAA) entra en vigor en junio de 2025 y exige que una amplia gama de productos y servicios digitales cumplan las normas de accesibilidad. Esto incluye plataformas de comercio electrónico, aplicaciones bancarias, sistemas de reserva de transporte y cualquier negocio que venda servicios digitales a consumidores de la UE. El incumplimiento puede acarrear multas, la retirada del producto del mercado y daños reputacionales. La EAA hace referencia explícita a las WCAG 2.1 como el estándar técnico que deben seguir las empresas.

WCAG 2.2, publicada en octubre de 2023, es la última versión de las Pautas de Accesibilidad para el Contenido Web que mantiene el W3C. Introduce nueve nuevos criterios de conformidad que abordan la accesibilidad móvil, las discapacidades cognitivas y los retos de autenticación. Las empresas sujetas a la ADA, la EAA o la Section 508 deberían fijar WCAG 2.2 nivel AA como base de cumplimiento. El nivel A aborda las barreras más críticas, el nivel AA cubre la mayoría de las necesidades de los usuarios y el nivel AAA representa el estándar de oro, pero a menudo resulta poco práctico de alcanzar en todo un sitio.

Más allá del cumplimiento legal, la accesibilidad tiene un sólido sentido empresarial. El poder de compra global de las personas con discapacidad y sus familias supera los 13 billones de dólares anuales, según el Return on Disability Group. Además, los sitios web accesibles tienden a posicionar mejor en los buscadores porque muchas buenas prácticas de accesibilidad, el HTML semántico, el texto alternativo descriptivo, las jerarquías de encabezados lógicas y el texto de enlace claro, también son buenas prácticas de SEO. Los algoritmos de Google premian el contenido estructurado y bien etiquetado, que es exactamente lo que proporciona un marcado accesible.

Los sitios accesibles también convierten mejor. Un estudio del Click-Away Pound Survey encontró que el 71% de los usuarios con discapacidad abandonan un sitio web difícil de usar, y el 82% de ellos gastarían más si la experiencia fuera accesible. Mejorar las etiquetas de los formularios, los mensajes de error y la claridad de la navegación beneficia a todos los usuarios, no solo a aquellos con discapacidad. Nuestros clientes de los sectores de sanidad y medicina obtienen retornos especialmente altos de las inversiones en accesibilidad porque sus audiencias incluyen pacientes mayores y cuidadores que dependen de tecnologías de asistencia.

La accesibilidad también protege su inversión de cara al futuro. A medida que se amplían las normativas y se intensifica su aplicación, las empresas que crean productos accesibles hoy evitan costosas correcciones mañana. Mantener la accesibilidad como práctica continua es mucho más económico que someterse a auditorías periódicas y arreglos de urgencia.

WCAG organiza sus directrices en torno a cuatro principios, recordados a menudo con el acrónimo POUR: perceptible, operable, comprensible y robusto. Perceptible significa que todo el contenido debe poder presentarse a los usuarios de formas que puedan percibir: las imágenes necesitan texto alternativo, los vídeos necesitan subtítulos y el color nunca debe ser el único medio para transmitir información. Operable significa que toda la funcionalidad debe ser accesible por teclado, que los usuarios deben disponer de tiempo suficiente para leer y usar el contenido y que nada debe provocar convulsiones o molestias físicas. Comprensible significa que el texto debe ser legible, que las páginas deben comportarse de forma predecible y que los formularios deben ayudar a los usuarios a evitar y corregir errores. Robusto significa que el contenido debe ser compatible con las tecnologías de asistencia actuales y futuras.

WCAG 2.2 añade varios criterios importantes. Los movimientos de arrastre deben tener alternativas de un solo puntero, de modo que un usuario que no pueda realizar un gesto de arrastre pueda reordenar elementos o mover controles deslizantes. El tamaño del objetivo de los elementos interactivos debe ser de al menos 24 por 24 píxeles CSS, lo que evita la frustración de los objetivos táctiles diminutos en dispositivos móviles. Los mecanismos de ayuda coherentes, como un chat de soporte o un enlace de contacto, deben aparecer en la misma ubicación relativa en todas las páginas. La apariencia del foco exige que los indicadores de foco del teclado cumplan umbrales mínimos de contraste y tamaño para que los usuarios siempre vean dónde están en la página.

Para aplicaciones web con interfaces complejas como paneles de control, tablas de datos e interacciones de arrastrar y soltar, el cumplimiento de WCAG exige una atención cuidadosa a los roles ARIA, las regiones dinámicas y la gestión del foco. Una tabla ordenable necesita atributos aria-sort. Un aviso de notificación necesita role="alert". Un diálogo modal necesita atrapar el foco y devolverlo al elemento que lo activó al cerrarse. Estos detalles son fáciles de pasar por alto, pero son críticos para los usuarios de lectores de pantalla.

El error de accesibilidad más frecuente en la web es la falta de texto alternativo en las imágenes. El estudio anual de WebAIM sobre el millón de sitios web más visitados reveló que el 54% de todos los errores detectados eran textos alternativos ausentes, enlaces vacíos o etiquetas de formulario ausentes. No son casos excepcionales, son los requisitos más básicos del marcado accesible y afectan a todos los usuarios de lectores de pantalla que visitan su sitio. Las imágenes decorativas deben usar alt="" (alt vacío) para que los lectores de pantalla las omitan, mientras que las imágenes informativas deben usar un texto alternativo conciso y descriptivo.

El bajo contraste de color es el segundo problema más común. WCAG exige una relación de contraste mínima de 4,5:1 para texto normal y de 3:1 para texto grande. Muchas tendencias de diseño populares, texto gris claro sobre fondos blancos, colores pastel y grosores de fuente finos, no cumplen estos umbrales. Herramientas como el WebAIM Contrast Checker o el analizador de contraste integrado en Chrome DevTools permiten verificar el cumplimiento en cuestión de segundos. No hay excusa para publicar texto que los usuarios no pueden leer.

Otro error frecuente es confiar únicamente en el color para transmitir significado. Un campo de formulario que se vuelve rojo para indicar un error pasa desapercibido para un usuario daltónico a menos que vaya acompañado de un icono, una etiqueta de texto o un cambio de patrón. Los indicadores de estado que usan solo verde, amarillo y rojo carecen de sentido para el 8 % de los hombres y el 0,5 % de las mujeres con deficiencia de visión cromática rojo-verde. Combine siempre el color con un indicador secundario como la forma, el texto o la iconografía.

Una auditoría de accesibilidad combina el escaneo automatizado con pruebas manuales para identificar barreras en todo su sitio web. Empiece con herramientas automatizadas: WAVE, axe DevTools y la auditoría de accesibilidad de Lighthouse pueden detectar automáticamente entre un 30 % y un 40 % de las infracciones de WCAG. Estas herramientas señalan en segundos textos alternativos ausentes, contraste insuficiente, botones vacíos y etiquetas de formulario ausentes. Ejecútelas en cada plantilla de página única, no solo en la página de inicio.

Las pruebas manuales cubren los problemas que la automatización no puede detectar. Navegue por todo su sitio web usando solo el teclado. Pulse Tab para avanzar, Mayús+Tab para retroceder, Intro para activar y Escape para cerrar. Todos los elementos interactivos deben ser alcanzables, mostrar el foco visualmente y poder usarse sin ratón. Después, pruebe con un lector de pantalla: VoiceOver en Mac, NVDA en Windows o TalkBack en Android. Escuche cómo se anuncian sus páginas y anote cualquier punto en el que la experiencia resulte confusa, repetitiva o incompleta.

Para una auditoría completa, involucre a usuarios con discapacidad. Ninguna cantidad de pruebas técnicas sustituye la perspectiva de alguien que depende a diario de tecnología de asistencia. Reclute de tres a cinco participantes con distintas discapacidades: ceguera, baja visión, discapacidad motriz, discapacidad cognitiva, y obsérvelos completar tareas clave en su sitio web. Los problemas que descubren casi siempre son distintos de los que señalan las herramientas automatizadas, y casi siempre son más importantes.

La accesibilidad empieza en la fase de diseño, no en la de desarrollo. Los diseñadores deben verificar los ratios de contraste de color antes de finalizar su paleta, definir los estados de foco de cada elemento interactivo junto con los estados hover y asegurarse de que los objetivos táctiles cumplan el mínimo de 44 por 44 píxeles recomendado por las Human Interface Guidelines de Apple (o, como mínimo, el requisito de 24 por 24 píxeles CSS de las WCAG 2.2). La tipografía también importa: un texto de cuerpo inferior a 16 píxeles resulta difícil de leer para muchos usuarios, y una altura de línea inferior a 1,5 reduce la legibilidad para las personas con dislexia.

La arquitectura de la información desempeña un papel importante en la accesibilidad cognitiva. Las páginas deben seguir una jerarquía lógica de encabezados (h1, h2, h3) que permita a los usuarios de lectores de pantalla navegar por nivel de encabezado. Los menús de navegación deben ser coherentes en todas las páginas. Los mensajes de error deben aparecer cerca del elemento que ha provocado el error, no en un banner genérico en la parte superior de la página. Los campos de formulario deben tener siempre etiquetas visibles, sin depender únicamente del texto de marcador de posición, que desaparece cuando el usuario empieza a escribir.

Los sistemas de diseño son la herramienta más eficaz para institucionalizar la accesibilidad. Cuando su componente de botón incorpora estilos de foco integrados, su componente de campo de entrada incorpora la asociación de etiquetas y su componente de modal incorpora la retención de foco, la accesibilidad pasa a ser el comportamiento predeterminado en lugar de algo opcional. Todos los componentes del sistema de diseño de GRADAX cumplen el nivel AA de las WCAG 2.2, así que nuestros desarrolladores nunca tienen que pensar en la accesibilidad básica: está integrada en los bloques con los que construyen.

El panorama de herramientas de accesibilidad ha madurado notablemente. Para el escaneo automatizado, axe-core (el motor detrás de axe DevTools) es el estándar del sector, con integraciones para todos los frameworks de pruebas principales. Para la monitorización continua, herramientas como Siteimprove, Deque y Tenon ofrecen paneles que siguen el cumplimiento en todo su dominio a lo largo del tiempo. Para la validación en fase de diseño, Stark y Polypane ofrecen comprobadores de contraste y simuladores de visión integrados directamente en la herramienta de diseño.

Las pruebas automatizadas en su pipeline de CI/CD garantizan que la accesibilidad no sufra regresiones. Herramientas como axe-playwright y jest-axe ejecutan comprobaciones de accesibilidad como parte de su suite de pruebas y hacen fallar la compilación si se introducen nuevas infracciones. Esto desplaza la accesibilidad hacia la izquierda en el proceso de desarrollo, detectando los problemas antes de que lleguen a producción en lugar de esperar a que un usuario se queje o un abogado envíe una carta de reclamación.

La accesibilidad no es un proyecto puntual, es una práctica continua. Cada nueva página, funcionalidad y actualización de contenido es una oportunidad para introducir o eliminar barreras. Incorpore la accesibilidad a su lista de control de calidad, forme a sus editores de contenido para que escriban textos alternativos descriptivos y encabezados semánticos, y reserve presupuesto para auditorías manuales periódicas realizadas por especialistas. Si quiere saber en qué punto se encuentra hoy su sitio web y qué haría falta para alcanzar el nivel AA de las WCAG 2.2, contacte con nuestro equipo para una evaluación integral de accesibilidad.