El 21 de octubre de 2025, el W3C anunció que WCAG 2.2 pasó a ser el estándar internacional ISO/IEC 40500:2025. La noticia tuvo buena recepción en comunidades de accesibilidad: tener un número ISO facilita el argumento en licitaciones públicas, en contratos de procurement y en conversaciones con equipos legales que no conocen las siglas del W3C pero sí reconocen a la ISO. Ese mismo mes, el grupo de trabajo del W3C tenía publicados ya cuatro borradores de la versión siguiente. El quinto se publicó en marzo de 2026.
Lo que viene no es WCAG 2.2 con más reglas. Tiene sentido que esa sea la primera lectura: WCAG 2.0, 2.1 y 2.2 fueron acumulativas, cada versión sumó criterios sobre la anterior sin cambiar la lógica de base, y los equipos que llevan años trabajando accesibilidad asumieron, razonablemente, que 3.0 seguiría el mismo patrón. El cambio más importante de WCAG 3.0 no está en la cantidad de requisitos sino en la lógica que los organiza. Entender esa diferencia es lo que separa a los equipos que van a transicionar bien de los que van a redescubrir en 2029 que llevan años preparándose para el estándar equivocado.
El límite del modelo binario
WCAG 2.2, como todas las versiones anteriores, funciona en binario: cada criterio de éxito pasa o falla. Un sitio que cumple todos los criterios de nivel AA dentro de su alcance declarado está conforme; uno que falla en uno solo de los 87 criterios relevantes no lo está. El modelo tiene una virtud real: es fácil de auditar y de litigar. Saber si una imagen tiene texto alternativo es una pregunta con respuesta binaria.
El problema es que el modelo produce resultados que no reflejan la experiencia real de los usuarios. Un sitio puede tener formularios completamente inaccesibles para personas que usan lectores de pantalla, compensarlo con imágenes perfectamente etiquetadas y atributos ARIA correctamente implementados en la navegación principal, y declarar conformidad AA. La auditoría no miente, pero la persona ciega que necesita completar ese formulario tampoco. El informe dice que el sitio pasa; la persona no puede usarlo.
El otro problema es de cobertura estructural. Cuando WCAG 2.0 se publicó en 2008, la web era en gran parte estática. El criterio 2.4.1, que permite saltar bloques de navegación repetitivos, asume que hay bloques que saltar y que la unidad de evaluación es una página cargada. Una aplicación de una sola página que actualiza el DOM sin recargar puede cumplir técnicamente ese criterio sin que tenga ningún efecto práctico para alguien navegando por teclado. El criterio es correcto para el contexto en que fue escrito; el modelo que lo contiene no ve el problema completo. WCAG 3.0 parte de reconocer ese límite.
Bronce, Plata y Oro: el nuevo sistema de conformidad
El borrador de marzo de 2026 propone un sistema de tres niveles: Bronce, Plata y Oro, donde cada requisito se evalúa en una escala de 0 a 4. El 0 es Muy Deficiente, el 1 es Deficiente, el 2 es Suficiente, el 3 es Bueno y el 4 es Excelente. Para alcanzar Bronce, el umbral mínimo de conformidad, se necesita un promedio de al menos 3,5 sobre 4 en todos los requisitos y dentro de cada categoría funcional por separado. Un puntaje de 2 en un requisito no descarta automáticamente la conformidad, pero arrastra el promedio de toda la categoría, y si esa categoría cae bajo 3,5, el nivel Bronce no se alcanza sin importar el resto.
Las categorías funcionales son el elemento central que la mayoría de los análisis omite. WCAG 3.0 organiza los requisitos en grupos que representan necesidades reales de distintos tipos de usuarios: orientación y navegación, entrada de datos, contenido visual, contenido auditivo, comprensión del contenido, entre otras. Un producto tiene que alcanzar el umbral dentro de cada categoría individualmente: no puede compensar una categoría débil con rendimiento alto en otra. Un sitio que domina el contraste de color pero ignora la navegación por teclado no llega a Bronce, aunque su promedio global sea de 3,7. Este diseño apunta directamente al problema que el modelo binario no podía resolver: una falla estructural en un área de alto impacto pesa en el resultado aunque todo lo demás funcione bien. Es lo que el borrador llama conformidad holística, evaluar la experiencia completa del usuario y no el cumplimiento punto por punto de criterios aislados.
WCAG 3.0 es también el primer estándar del W3C que trata la accesibilidad cognitiva como una prioridad de diseño, no como un caso borde. Las versiones anteriores se enfocaban principalmente en discapacidades sensoriales y motoras. WCAG 3.0 incorpora requisitos específicos para personas con dislexia, TDAH y deterioro cognitivo dentro de la categoría de comprensión del contenido: evalúa si el lenguaje es claro, si los errores se explican de forma que el usuario pueda corregirlos, y si la carga cognitiva de la interfaz es manejable. Son los requisitos más difíciles de evaluar con herramientas automáticas, y también los más ignorados en auditorías actuales.
El contraste de color es el área donde el cambio técnico es más visible a nivel de implementación. WCAG 2.2 usa una fórmula matemática simple para el ratio de contraste, la misma desde 2008, que trata todos los contextos de visualización como equivalentes. WCAG 3.0 propone reemplazarla con APCA (Accessible Perceptual Contrast Algorithm), un algoritmo que considera el tamaño y peso tipográfico, el tono del fondo y cómo el ojo humano percibe el contraste en condiciones distintas. Los valores que hoy pasan el criterio 1.4.3 de WCAG 2.2 AA pueden no pasar APCA, y algunos que hoy fallan pueden resultar aceptables bajo el nuevo modelo. Para equipos con sistemas de diseño consolidados, este cambio tiene implicancias directas en los tokens de color.
El nivel Bronce está calibrado para alinearse con WCAG 2.2 nivel AA. Plata y Oro requieren porcentajes crecientes de requisitos suplementarios además del núcleo obligatorio; los detalles exactos siguen en definición en el borrador actual. Para la mayoría de los equipos de producto en LATAM, Bronce es el objetivo relevante por ahora y durante los próximos años.
174 requisitos: qué hay detrás del número
El borrador de marzo de 2026 incluye 174 requisitos, más del doble que los 87 criterios de éxito de WCAG 2.2. La diferencia de estructura explica parte del crecimiento. WCAG 3.0 organiza cada elemento en cuatro capas: la Directriz (el objetivo general), el Requisito (lo que debe cumplirse), las Aserciones (afirmaciones verificables de conformidad) y los Métodos de Prueba (cómo testear cada aserción en una tecnología concreta). Lo que en WCAG 2.2 era un solo criterio con un conjunto de técnicas asociadas, en WCAG 3.0 se desagrega en requisitos separados con métodos de testeo propios para cada contexto.
El ejemplo más claro está en el texto alternativo para imágenes. WCAG 2.2 tiene un único criterio, 1.1.1 Non-text Content, que cubre imágenes decorativas, funcionales, complejas e imágenes en formularios dentro del mismo ítem. WCAG 3.0 separa cada caso en su propio requisito, con métodos de testeo específicos para cada tipo. No es trabajo duplicado: es mayor precisión en qué evaluar y cómo hacerlo en contextos distintos. Una imagen decorativa y una imagen que actúa como botón tienen fallas de accesibilidad completamente diferentes y merecen tratamientos separados.
Los 174 representan únicamente los requisitos que han alcanzado estado de desarrollo en el borrador actual. Los requisitos todavía en fase exploratoria no están incluidos. Las plataformas de terceros (gestores de contenido, APIs, sistemas donde el desarrollador no controla directamente el código de accesibilidad) tampoco tienen tratamiento definitivo aún. El número final cuando WCAG 3.0 llegue a Recomendación va a ser mayor.
El fin del modelo centrado en páginas
WCAG 2.2 fue construido asumiendo que la unidad básica de evaluación era la página web. Ese supuesto se volvió un problema a medida que los productos digitales dejaron de ser páginas. Una app de banca móvil que gestiona autenticación biométrica, notificaciones push y transferencias en tiempo real no tiene "páginas" en el sentido que el estándar asume. Evaluarla con el modelo de WCAG 2.2 requiere interpretaciones y ajustes que el estándar no contempla de forma explícita, lo que genera inconsistencias entre auditorías distintas sobre el mismo producto.
WCAG 3.0 abandona esa unidad. Los requisitos son agnósticos respecto a la tecnología: el mismo principio de accesibilidad aplica a un sitio web, a una app móvil o a un entorno de realidad virtual, con métodos de testeo específicos para cada superficie. El borrador incluye ya requisitos para entornos inmersivos, entre ellos que los subtítulos en realidad virtual deben permanecer posicionados frente al usuario independientemente de la dirección en que mire. Ese tipo de requisito no tiene equivalente en ninguna versión de WCAG 2 porque el contexto para el que fue diseñado no existía cuando esas versiones se escribieron.
Para equipos de producto que desarrollan apps y no páginas, este cambio de modelo importa más que cualquier cantidad de requisitos. Los fundamentos de la accesibilidad dejan de estar atados a una estructura que sus productos nunca tuvieron. Una auditoría WCAG 3.0 sobre una app de gestión hospitalaria va a evaluar flujos completos: cómo un usuario de lector de pantalla agenda una cita, recibe confirmación y accede a su historial, y no si cada pantalla individual cumple un checklist de criterios pensados para documentos HTML estáticos.
Qué hace un equipo que ya cumple WCAG 2.2
La primera respuesta que el borrador de WCAG 3.0 debería generar en un equipo que ya trabaja accesibilidad en serio es calma. El nivel Bronce está calibrado para absorber el cumplimiento AA actual. No hay un escenario en el que un equipo que hoy pasa una auditoría WCAG 2.2 AA rigurosa tenga que rehacer su trabajo desde cero cuando llegue WCAG 3.0. El piso del nuevo estándar está donde la mayoría de los equipos avanzados ya están.
Lo que sí cambia es cómo se documenta y evalúa ese trabajo. Si el proceso actual depende principalmente de herramientas automáticas de detección como Axe, Wave o Lighthouse, sin complemento de testeo manual ni pruebas con usuarios reales, ese proceso va a alcanzar su límite con el nuevo modelo. Las herramientas automáticas detectan errores de markup, contraste y atributos faltantes; no evalúan si una experiencia es comprensible para alguien con discapacidad cognitiva, si los flujos de formularios son operables sin fricción excesiva, o si la navegación por teclado en una interfaz dinámica es realmente funcional. El sistema de scoring de WCAG 3.0 tiene requisitos que solo se pueden evaluar con testeo humano. Un equipo que ya incorpora ese testeo tiene poco que ajustar metodológicamente; uno que no lo hace tiene una deuda que conviene saldar independientemente de WCAG 3.0.
El otro ajuste útil es mapear los productos digitales por superficie y no por URL: qué sistema de diseño se usa, qué componentes tienen comportamiento dinámico, qué plataformas de terceros inyectan código sin control directo del equipo. Las librerías de componentes como Material UI, Radix o Chakra van a necesitar actualizar sus métodos de testeo cuando WCAG 3.0 se formalice. Saber qué partes de la interfaz dependen de esas librerías y cuáles son propias del equipo es, también, saber dónde está el riesgo cuando llegue la transición.
Ninguno de esos pasos tiene urgencia regulatoria. WCAG 3.0 no tiene fecha de publicación final; los estimados más citados ubican la Recomendación entre 2028 y 2030, y las legislaciones nacionales tardan años adicionales en adoptarla formalmente. Lo que no va a cambiar es la dirección del estándar. El trabajo relevante para un equipo hoy no es prepararse para WCAG 3.0: es construir los procesos que hacen que la transición, cuando llegue, no requiera partir de cero.
Chile y WCAG 3.0: lo que la normativa local no ha resuelto
El Decreto Supremo N° 1, que reglamenta la Ley 20.422 para el Estado, establece WCAG 2.0 AA como piso legal de accesibilidad web en Chile. En la práctica, el Manual de Accesibilidad Web del Kit Digital ya integra WCAG 2.1, aunque sin fuerza normativa equivalente. Ningún instrumento oficial chileno referencia aún WCAG 2.2, que desde octubre de 2025 es el estándar ISO vigente a nivel internacional. Las organizaciones que trabajan con las pautas de inclusión digital actuales no incumplen la normativa local, pero operan sobre un marco que lleva al menos una versión de retraso. Con WCAG 3.0 en borrador activo, esa distancia solo va a crecer.
La parte que el borrador todavía no resuelve es la más compleja de la web actual: cómo aplicar los requisitos en entornos donde el desarrollador no controla la plataforma completa. Las APIs de terceros, los gestores de contenido y los sistemas de componentes compartidos entre organizaciones quedan en una zona gris que el siguiente ciclo de trabajo del grupo tiene que definir. Son también los entornos donde los problemas de accesibilidad más persistentes ocurren, y donde WCAG 3.0, cuando llegue, va a tener que mostrar si el nuevo modelo resuelve lo que el anterior no pudo.