Recursos de accesibilidad

Una breve historia de la accesibilidad web

Mucho antes de que existiera la web, la legislación federal de EE. UU. ya había empezado a construir el andamiaje legal al que la accesibilidad se engancharía más tarde. La Sección 504 de la Ley de Rehabilitación de 1973 prohibió la discriminación por motivos de discapacidad por parte de cualquier programa que recibiera ayuda económica federal, aunque el reglamento de desarrollo no se firmó hasta el 28 de abril de 1977, y solo después de la famosa sentada de la 504, en la que activistas por los derechos de las personas con discapacidad ocuparon un edificio federal de San Francisco durante 25 días, la ocupación no violenta más larga de un edificio federal en la historia de EE. UU. La Sección 508 de la misma ley se añadió por enmienda en 1986, pero no tenía capacidad sancionadora; la versión sustancialmente revisada a la que se refieren hoy los profesionales se promulgó en 1998 como parte de la Workforce Investment Act, que obliga a las agencias federales de EE. UU. a hacer accesible su tecnología electrónica y de la información. La Ley de Estadounidenses con Discapacidades de 1990 (ADA) es el estatuto de derechos civiles más amplio que prohíbe la discriminación por discapacidad, y es la ADA (no la Sección 508) la que se invoca en las demandas contra sitios web del sector privado.

El W3C puso en marcha la Iniciativa de Accesibilidad Web (WAI) en 1997 para coordinar el trabajo de accesibilidad web en toda la comunidad que fija los estándares. El planteamiento de Tim Berners-Lee (que el valor de la web reside en la universalidad y que el acceso de todas las personas, sea cual sea su discapacidad, es esencial) se convirtió en la premisa fundacional de la WAI.

La cronología de versiones de las WCAG

• WCAG 1.0: recomendación del W3C, 5 de mayo de 1999. Organizó los consejos de accesibilidad en torno a 14 pautas con puntos de verificación clasificados como Prioridad 1, 2 o 3 (los niveles de conformidad A, AA y AAA heredan este esquema). Firmemente orientada a HTML y a la pila tecnológica de la web temprana de finales de la década de 1990.
• WCAG 2.0: recomendación del W3C, 11 de diciembre de 2008. Reorganizó todo el marco en torno a los cuatro principios POUR. Introdujo el modelo de conformidad de tres niveles aún vigente (A / AA / AAA). Adoptada como ISO/IEC 40500:2012 en octubre de 2012.
• WCAG 2.1: recomendación del W3C, 5 de junio de 2018. Añadió 17 nuevos criterios de éxito dirigidos a los usuarios de móvil (orientación de la pantalla, gestos de puntero, accionamiento por movimiento), a los usuarios con baja visión (reajuste a 320 píxeles CSS, contraste no textual de 3:1 para los componentes de la interfaz, tolerancia al espaciado del texto) y a las personas con discapacidades cognitivas y de aprendizaje (propósito del campo de autorrelleno, ayuda con los tiempos de espera). «WCAG 2.1 AA» sigue siendo el estándar más citado en la legislación de accesibilidad de todo el mundo.
• WCAG 2.2: recomendación del W3C, 5 de octubre de 2023, con actualizaciones de mantenimiento editorial publicadas en diciembre de 2024. Añadió nueve nuevos criterios de éxito, entre ellos Foco no oscurecido (2.4.11/2.4.12), Movimientos de arrastre (2.5.7), Tamaño mínimo del objetivo (2.5.8, al menos 24×24 píxeles CSS), Ayuda coherente (3.2.6), Entrada redundante (3.3.7) y Autenticación accesible (3.3.8/3.3.9; los flujos de inicio de sesión no pueden exigir CAPTCHA de tipo rompecabezas sin una alternativa accesible). Eliminó el obsoleto criterio 4.1.1 Análisis sintáctico. Esta es la versión publicada actual.
• WCAG 3.0: todavía un borrador de trabajo. Diseñada con un modelo de puntuación más flexible y un alcance más amplio (apps, herramientas de autoría, plataformas de publicación, tecnologías emergentes). El W3C deja claro que WCAG 3 no sustituirá a WCAG 2 de inmediato: WCAG 2 se seguirá manteniendo durante varios años después de que se finalice la 3. Los profesionales que redacten declaraciones de accesibilidad en 2026 deberían seguir tomando como referencia WCAG 2.2 (o 2.1) como estándar operativo.

Los cuatro principios POUR en lenguaje sencillo

Perceptible pregunta: ¿puede el usuario captar realmente lo que hay en la pantalla? Una fotografía sin texto alternativo no es perceptible para quien usa un lector de pantalla. Un vídeo sin subtítulos no es perceptible para una persona sorda. Un texto en gris oscuro de 9 puntos sobre un gris un poco menos oscuro no es perceptible para muchas personas con baja visión. «Perceptible» no significa «que se ve bonito», significa «¿está presente la información en una forma que los sentidos y las herramientas de este usuario puedan captar?».

Operable pregunta: ¿puede el usuario usar realmente la interfaz? Un sitio que exige pasar el ratón por encima no es operable para los usuarios de teclado o de pantalla táctil. Un tiempo de espera de 60 segundos no es operable para alguien que necesita más tiempo para leer. Una ventana modal que atrapa el foco del teclado sin escapatoria no es operable.

Comprensible pregunta: ¿puede el usuario entender lo que está pasando? Un formulario que dice «Error 47» y nada más no es comprensible. Una página cuya navegación se reorganiza de forma distinta en cada visita no es comprensible.

Robusto pregunta: ¿seguirá funcionando el contenido a medida que evolucionen los agentes de usuario y las tecnologías de asistencia? Los componentes personalizados que no exponen roles, nombres y estados adecuados al árbol de accesibilidad incumplen este principio. El consejo práctico más común: prioriza los elementos HTML estándar frente a los widgets de JavaScript personalizados siempre que sea posible; cuando construyas widgets personalizados, sigue los patrones ARIA documentados por el W3C.

WAI-ARIA, el complemento para aplicaciones enriquecidas

WAI-ARIA es una especificación aparte del W3C que define roles, estados y propiedades que HTML puede llevar para comunicar el propósito y el estado actual de los componentes de interfaz dinámicos a las tecnologías de asistencia. ARIA es necesario porque HTML por sí solo no puede describir patrones modernos como las pestañas, los diálogos, los cuadros combinados de autocompletado, las vistas de árbol y las regiones activas que se actualizan sin recargar la página. Cronología de versiones: WAI-ARIA 1.0, recomendación del 20 de marzo de 2014; 1.1, del 14 de diciembre de 2017; 1.2, del 6 de junio de 2023, la versión actual. Las cinco «reglas de uso de ARIA» se resumen en: prioriza el HTML nativo; no cambies la semántica de los elementos existentes; garantiza la operabilidad por teclado; nunca ocultes elementos enfocables a la tecnología de asistencia; y da siempre a cada elemento interactivo un nombre accesible.

El panorama legal, jurisdicción por jurisdicción

En Estados Unidos, las demandas por accesibilidad web se presentan casi por completo al amparo del Título III de la ADA. Dos casos definieron el panorama moderno. National Federation of the Blind contra Target Corp. (presentada el 7 de febrero de 2006, resuelta en agosto de 2008 por 6 millones de dólares más 3,7 millones en honorarios de los abogados) fue la primera gran demanda colectiva de accesibilidad web en EE. UU. Robles contra Domino's Pizza: fallo del Noveno Circuito el 15 de enero de 2019; el Tribunal Supremo se negó a admitir el recurso el 7 de octubre de 2019, lo que confirmó que la ADA alcanza a cualquier plataforma en línea de una empresa estadounidense con ubicaciones físicas. El resultado ha sido un auge sostenido de las demandas: 4.187 demandas federales de accesibilidad digital en 2024, con más de 4.000 cada año desde 2021. Alrededor de una cuarta parte de los casos de 2024 implicaban a empresas que ya habían sido demandadas antes. Cabe destacar que más de 1.000 de los demandados de 2024 ya habían instalado un «widget de accesibilidad» (los scripts de tipo superposición que se promocionan mucho a las pequeñas empresas), lo que no evitó la demanda.

En abril de 2024, el Departamento de Justicia de EE. UU. finalizó una norma largamente esperada que aplica el Título II de la ADA al contenido web y las apps móviles de los gobiernos estatales y locales. La norma se publicó en el Federal Register el 24 de abril de 2024 y adoptó el nivel AA de WCAG 2.1 como estándar técnico. En abril de 2026, el DOJ amplió un año los plazos originales mediante una norma final provisional: las grandes entidades públicas tienen ahora hasta el 26 de abril de 2027, y las pequeñas entidades hasta el 26 de abril de 2028.

La Ley Europea de Accesibilidad es la Directiva (UE) 2019/882, adoptada en abril de 2019. Los Estados miembros tuvieron que transponerla a su legislación nacional antes del 28 de junio de 2022, y los requisitos sustantivos de accesibilidad empezaron a aplicarse el 28 de junio de 2025. La EAA abarca una amplia gama de productos y servicios de consumo que se comercializan en el mercado de la UE: ordenadores y sistemas operativos, teléfonos inteligentes y tabletas, lectores de libros electrónicos, cajeros automáticos y máquinas de venta de billetes o de facturación, sitios web de comercio electrónico, servicios bancarios, libros electrónicos, servicios de medios audiovisuales e información sobre el transporte de pasajeros. Las microempresas (menos de 10 empleados, facturación inferior a 2 millones de euros) que prestan servicios están exentas. El estándar técnico armonizado es EN 301 549, publicado conjuntamente por CEN, CENELEC y ETSI; la versión actual, la 3.2.1 (marzo de 2021), incorpora el texto completo de WCAG 2.1.

Otros marcos nacionales importantes: la AODA de Ontario (Accessibility for Ontarians with Disabilities Act), promulgada en 2005 con el objetivo declarado de lograr la accesibilidad plena para 2025; el RGAA de Francia (Référentiel Général d'Amélioration de l'Accessibilité) v4.1.2 (2022), un conjunto de 106 criterios técnicos correlacionados con WCAG 2.1 AA, con multas sustanciales por incumplimiento para el sector público y las grandes empresas privadas (facturación anual de 250 millones de euros o más).

Quién usa realmente tu sitio: el panorama de la tecnología de asistencia

Los datos más fiables sobre las combinaciones de lector de pantalla y navegador proceden de la Encuesta de usuarios de lectores de pantalla de WebAIM. La edición más reciente, la Encuesta n.º 10, se realizó en diciembre de 2023 y enero de 2024 y obtuvo 1.539 respuestas válidas. Cifras destacadas: como lector de pantalla principal, JAWS 40,5 %, NVDA 37,7 %, VoiceOver 9,7 %. Como «el más usado en general» (opción múltiple), NVDA 65,6 %, JAWS 60,5 %, VoiceOver 43,9 %: alrededor del 71,6 % de los encuestados usan más de un lector de pantalla. Las combinaciones más comunes son JAWS + Chrome (24,7 %), NVDA + Chrome (21,3 %), JAWS + Edge (11,4 %), NVDA + Firefox (10,0 %) y VoiceOver + Safari (7,0 %).

• JAWS (Job Access With Speech), lector de pantalla comercial para Windows, lanzado originalmente en 1989 por Ted Henter a través de Henter-Joyce, ahora parte de Vispero. Dominante en las empresas y la Administración de EE. UU.
• NVDA (NonVisual Desktop Access), el principal lector de pantalla gratuito y de código abierto para Windows, lanzado por primera vez en abril de 2006 por Michael Curran y James Teh (ambos ciegos). La organización sin ánimo de lucro NV Access se constituyó a principios de 2007. El crecimiento de NVDA ha sido la tendencia más llamativa del mercado de lectores de pantalla en la última década.
• VoiceOver: integrado en los sistemas operativos de Apple. Debutó en Mac OS X 10.4 Tiger (2005); se añadió a iOS con el iPhone 3GS (2009). Ahora se incluye en macOS, iOS, iPadOS, tvOS y watchOS.
• TalkBack: el lector de pantalla integrado equivalente en Android, mantenido por Google.

Otras tecnologías de asistencia del ecosistema más amplio: los ampliadores de pantalla (ZoomText para Windows, el ampliador integrado de macOS), el software de reconocimiento de voz (Dragon NaturallySpeaking), los dispositivos de acceso por conmutador para usuarios con control motor limitado, los teclados alternativos y los punteros de cabeza, los sistemas de seguimiento ocular y las líneas braille actualizables. Los criterios de las WCAG abordan todos ellos incluso cuando la página solo piensa en los lectores de pantalla.

El contraste de color, el modelo de WCAG 2 y el candidato APCA

WCAG 2.x mide el contraste como una relación de luminancia entre dos colores, un número que va de 1:1 (sin contraste) a 21:1 (blanco puro sobre negro puro). Los umbrales: nivel AA, texto normal 4,5:1; texto grande (18 pt o 14 pt en negrita) 3:1; nivel AAA, texto normal 7:1; texto grande 4,5:1. El §1.4.11 Contraste no textual de WCAG 2.1 añadió un requisito de 3:1 en AA para los componentes de la interfaz y los objetos gráficos que transmiten información.

El modelo de relación de luminancia tiene debilidades conocidas, en particular que exagera el contraste percibido de los colores oscuros: un par de dos colores oscuros con 4,5:1 puede resultar funcionalmente ilegible aunque técnicamente cumpla. El APCA (Accessible Perceptual Contrast Algorithm, algoritmo de contraste perceptual accesible), desarrollado por Andrew Somers, es un sustituto basado en la percepción diseñado para pantallas autoiluminadas. Es el método de contraste candidato para WCAG 3.0, y por ahora no forma parte de ninguna versión publicada de las WCAG. El APCA produce un número con signo en una escala de aproximadamente -108 a +108 (negativo cuando el texto claro se sitúa sobre un fondo oscuro). Los profesionales que publiquen en 2026 deberían seguir comprobando frente a las relaciones de WCAG 2.x como requisito legal, y tratar las puntuaciones APCA como comprobaciones perceptuales complementarias.

El estado del campo, en cifras

La instantánea anual más citada es el informe Million de WebAIM, que desde 2019 realiza comprobaciones automáticas de accesibilidad en las páginas de inicio del millón de sitios web más importantes del mundo. La edición WebAIM Million 2026, publicada en marzo de 2026, es la más reciente en el momento de escribir esto. El 95,9 % de las páginas de inicio tenían fallos de WCAG 2 detectados (frente al 94,8 % de 2025, la primera reversión de una tendencia de mejora de seis años). La página media tenía 56,1 errores de accesibilidad detectados, un aumento interanual del 10,1 %. Los seis tipos de error más comunes representan alrededor del 96 % de todos los problemas detectados:

1. Texto de bajo contraste: 83,9 % de las páginas, con una media de ~34 apariciones por página
2. Falta de texto alternativo en las imágenes, 53,1 %
3. Falta de etiquetas en los formularios: 51,0 %
4. Enlaces vacíos: 46,3 %
5. Botones vacíos: 30,6 %
6. Falta de declaración del idioma del documento: 13,5 %

Para poner en contexto: 1.300 millones de personas en todo el mundo, alrededor del 16 % de la población mundial, o aproximadamente 1 de cada 6, sufren una discapacidad significativa, según la ficha informativa de la Organización Mundial de la Salud actualizada por última vez el 7 de marzo de 2023.

De dónde proceden los recursos de este directorio

El directorio anterior se nutre del reducido número de organizaciones y proyectos que definen de hecho el campo:

• Iniciativa de Accesibilidad Web del W3C (WAI). El propio organismo de estándares. Los dos grupos de trabajo más activos para los equipos de sitios web son el Grupo de Trabajo de Pautas de Accesibilidad (que mantiene las WCAG) y el Grupo de Trabajo de ARIA (que mantiene WAI-ARIA). La WAI publica páginas de introducción, especificaciones técnicas detalladas, la Referencia rápida y cursos educativos gratuitos en edX.
• WebAIM (Web Accessibility In Mind). Fundada en 1999 en el Centro para Personas con Discapacidad de la Universidad Estatal de Utah. Opera la herramienta de evaluación WAVE, realiza la Encuesta de usuarios de lectores de pantalla y el WebAIM Million, y publica una de las bibliotecas de artículos prácticos de accesibilidad más consultadas de la web.
• Deque Systems. Fundada en 1999, con sede en Herndon, Virginia. Editora del motor de reglas axe-core, que liberó como código abierto en junio de 2015. Deque también gestiona Deque University y produce la extensión de navegador axe DevTools, que hoy es el verificador automático estándar del sector.
• A11Y Project. Un recurso y una biblioteca de patrones de código abierto impulsados por la comunidad, fundados en 2013. Conocido sobre todo por su lista de comprobación de accesibilidad ampliamente compartida; todo el sitio está en GitHub para la contribución de la comunidad.
• Asociación Internacional de Profesionales de la Accesibilidad (IAAP). Organismo profesional fundado el 19 de marzo de 2014, que se convirtió en una división de G3ict en julio de 2016. Administra las certificaciones reconocidas del sector (CPACC, WAS, CPWA, ADS).
• MDN Web Docs. La referencia para desarrolladores de Mozilla, que incluye la sección de accesibilidad mantenida que documenta ARIA, la semántica y los patrones de accesibilidad desde la perspectiva de la implementación por parte de los desarrolladores.

Juntándolo todo: la respuesta práctica a «¿con qué estándar debo cumplir?» en 2026 es WCAG 2.1 AA como mínimo (porque la mayoría de las leyes todavía lo citan) y WCAG 2.2 AA como objetivo de futuro. La respuesta práctica en cuanto a herramientas de prueba es axe DevTools para la automatización más un lector de pantalla real (NVDA + Chrome en Windows, VoiceOver + Safari en macOS) para las partes que ninguna herramienta automática puede detectar; la propia Deque describe axe como capaz de detectar «hasta el 80 % de los problemas», y la mayoría de las estimaciones independientes sitúan la detección automática en el 30-50 % de la conformidad total con las WCAG. Sigue siendo necesaria la prueba manual con un lector de pantalla real.