WCAG 2.2 es ahora el objetivo AA de referencia en toda la UE a través de la Ley Europea de Accesibilidad y la norma armonizada EN 301 549, y es el estándar de facto que los tribunales estadounidenses usan para medir los sitios web cubiertos por la ADA, incluso donde las regulaciones todavía mencionan la versión 2.1. La norma está bien documentada; el camino desde «sabemos que debemos cumplir» hasta «tenemos una postura defendible» no lo está. Esta guía es ese camino, en seis pasos, en el orden en que un equipo debe ejecutarlos realmente.

WCAG 2.2 es la versión actual de las Pautas de Accesibilidad para el Contenido Web, publicada por el W3C como Recomendación en octubre de 2023. Define 86 criterios de conformidad organizados bajo cuatro principios: el contenido debe ser perceptible, operable, comprensible y robusto. A cada criterio se le asigna un nivel de conformidad. El nivel A es el umbral mínimo; el nivel AA es el estándar de referencia que todos los principales reguladores mencionan; el nivel AAA es aspiracional y no constituye un suelo regulatorio en ningún lugar.

Cuando un regulador o un contrato dice «conformidad con WCAG 2.2 AA», significa algo más que superar la prueba en una página. La definición de conformidad del W3C exige que toda la unidad de conformidad —la página o el conjunto de páginas que constituyen un proceso— cumpla todos los criterios de nivel A y AA, que cualquier proceso sea accesible de principio a fin y que la tecnología de apoyo no tenga que desactivarse para que el contenido funcione. Un sitio que cumple la mayoría de los criterios en la mayoría de las páginas no es conforme; la exigencia es una cobertura total.

WCAG 2.2 añade nueve nuevos criterios sobre la versión 2.1: apariencia del foco, tamaño del objetivo, arrastre, entrada redundante, autenticación accesible, ayuda coherente y algunos otros. Los sitios que eran conformes con la versión 2.1 AA no lo son automáticamente con la 2.2 AA; los nuevos criterios son donde se produce la brecha. La fuente de verdad criterio por criterio se encuentra en nuestra referencia completa de criterios de conformidad WCAG 2.2.

El cumplimiento es una postura, no un estado: un sitio que es conforme el lunes puede publicar una regresión el martes. Tratarlo como un proyecto puntual es el error más común y más costoso del campo.

No se puede corregir lo que no se ha medido, y una sola herramienta no lo medirá bien. Una auditoría de referencia se ejecuta en tres modalidades sobre aproximadamente el mismo conjunto de páginas.

Modalidad 1 — Escaneo automatizado. Un escáner notifica los fallos comprobables por máquina: texto alternativo ausente, etiquetas de formulario ausentes, bajo contraste de color, ARIA inválido, problemas en la estructura de encabezados. Detecta los problemas densos y repetitivos que un ingeniero tendría que buscar manualmente, pero no puede juzgar si el texto alternativo es significativo, si un widget personalizado funciona bien con un lector de pantalla o si el orden del foco tiene sentido cognitivo. Trate el escaneo como una línea de base de volumen, no como un veredicto. Comience ejecutando el escáner gratuito de WCAG 2.2 en sus diez páginas principales: inicio, inicio de sesión, proceso de compra, dos páginas de producto, panel de control, configuración de cuenta, la página de declaración de accesibilidad si existe y las dos páginas de destino con mayor tráfico. El escaneo le indica si tiene cien problemas o diez mil, que es lo primero que necesita saber el responsable de la corrección.

Modalidad 2 — Revisión manual por un especialista en accesibilidad. Un revisor formado que trabaja sobre las mismas páginas detecta lo que la automatización no puede juzgar. ¿Es preciso el texto alternativo? ¿Es lógica la estructura de encabezados, no solo sintácticamente válida? ¿Los widgets personalizados exponen el nombre, rol y estado correctos? Un especialista revisa unas quince o veinte páginas por día; el resultado es un informe escrito con pasos de reproducción mapeados a criterios de conformidad específicos.

Modalidad 3 — Auditoría de usabilidad con personas que usan tecnología de apoyo. Un usuario de lector de pantalla realiza el proceso de compra; un usuario que solo usa el teclado navega por el panel de control; un usuario con baja visión rellena el formulario de contacto con un zoom del 200 por ciento. El resultado es cualitativo —«el anuncio al enviar ocurre antes de que el foco se mueva, así que me lo perdí»— y es la capa que distingue el cumplimiento de la accesibilidad real. Esta modalidad es la que las organizaciones omiten con más frecuencia; si se omite, se superarán los escaneos y las declaraciones mientras los usuarios siguen sin poder completar sus tareas.

Las tres modalidades se complementan: la automatización encuentra el volumen, la revisión especializada encuentra los problemas estructurales y semánticos, y las pruebas con usuarios encuentran los fallos de experiencia. Una primera línea de base que ejecute las tres tarda entre dos y cuatro semanas para un sitio de tamaño medio.

Una auditoría de referencia en un sitio típico detecta cientos o miles de problemas. Empezar por la parte superior de una lista plana es una forma de pasar tres meses sin avanzar. La clasificación opera en dos ejes: gravedad y alcance.

La gravedad es cuánto interrumpe el problema la experiencia. Los bloqueantes impiden completar la tarea: un botón de pago que los lectores de pantalla no pueden activar, un campo de formulario sin etiqueta programática, un modal que atrapa el foco. Los problemas principales generan una fricción significativa pero no bloquean: texto de enlace ambiguo, estilos de foco ausentes, mensajes de error visibles pero no anunciados. Los problemas menores son cosméticos o afectan solo a configuraciones AT reducidas: contraste ligeramente por debajo de 4,5:1, texto alternativo decorativo con un espacio al final, un nivel de encabezado omitido en una página de notas al pie.

El alcance es cuántos usuarios se ven afectados por el problema. Un enlace ambiguo en la navegación global llega a cada visitante en cada página. Un selector de fechas inaccesible en el proceso de compra llega a cada comprador. Un componente inaccesible en la página del dossier de prensa llega a casi nadie. El alcance lo determina la analítica, no el interés intrínseco del problema.

Una sencilla matriz de dos por dos es suficiente. El objetivo no es la precisión, sino forzar la conversación de que «bloquear a un lector de pantalla para completar el proceso de compra» no es el mismo problema que «un atributo alt con un espacio al final en la página de prensa».

La clasificación produce un backlog priorizado. El backlog, no el informe de auditoría, es contra lo que trabaja ingeniería.

El trabajo de corrección se divide en los mismos patrones en casi todos los sitios. Cada categoría se corresponde con uno o más criterios de conformidad WCAG; la referencia completa de criterios de conformidad WCAG 2.2 es la fuente de verdad.

Estructura HTML semántica. La corrección de mayor impacto es usar el elemento correcto. Un button no es un div con un manejador de clic; un encabezado no es texto en negrita; una lista no son párrafos separados por saltos de línea. El HTML nativo proporciona nombre, rol y comportamiento de teclado de forma gratuita; reinventarlo con ARIA sobre un elemento genérico es cómo se introducen la mayoría de los errores de accesibilidad. Mapeado a los criterios 1.3.1 y 4.1.2.

Texto alternativo para imágenes. Toda imagen significativa necesita un texto alternativo descriptivo. Las imágenes decorativas reciben alt="", no un atributo ausente. Las imágenes funcionales —iconos dentro de botones, enlaces de imagen— reciben texto alternativo que describe la acción, no la imagen. Mapeado al criterio 1.1.1.

Accesibilidad por teclado. Todos los elementos interactivos deben ser alcanzables y operables únicamente con el teclado: tabulador para llegar, Intro o Espacio para activar, Escape para salir. Los widgets personalizados (menús desplegables, modales, pestañas, carruseles, selectores de fechas) son los habituales infractores. Pruebe desconectando el ratón. Mapeado a los criterios 2.1.1 y 2.1.2.

Gestión del foco. Cuando el foco llega a un elemento debe ser visible, y cuando algo cambia en la página el foco debe situarse en algún lugar lógico. Un modal que se abre debe mover el foco hacia él; cerrarlo debe devolver el foco al elemento que lo activó. WCAG 2.2 añadió el criterio 2.4.11 Foco no oculto y reforzó el criterio 2.4.7 Foco visible; el anillo de foco ya no es un refinamiento opcional.

Contraste de color. El texto sobre su fondo debe alcanzar 4,5:1 para texto normal y 3:1 para texto grande bajo el criterio 1.4.3; los componentes de interfaz interactivos y los gráficos deben alcanzar 3:1 bajo el criterio 1.4.11. La mayoría de las infracciones se encuentran en superficies de marketing: colores de marca que parecen correctos en el monitor calibrado de un diseñador y fallan en un portátil real. Un comprobador de contraste en las herramientas de diseño previene la mayoría de las regresiones.

Etiquetas de formulario y mensajes de error. Cada campo necesita una etiqueta programática, no un marcador de posición. Los errores deben anunciarse a la tecnología de apoyo, asociarse al campo que los produjo y describirse en un lenguaje accionable. «Entrada no válida» no es una etiqueta; «El número de teléfono debe incluir el código de país» sí lo es.

ARIA: restricción, no entusiasmo. Utilice ARIA solo cuando el HTML nativo no pueda expresar lo que hace el componente. Un nav es mejor que role="navigation"; un button es mejor que role="button". El ARIA incorrecto es peor que ningún ARIA porque desinforma activamente a la tecnología de apoyo.

Anuncios de contenido dinámico. Cuando el contenido cambia sin una recarga de página —notificaciones emergentes, mensajes de validación, resultados de búsqueda que se actualizan en tiempo real— los lectores de pantalla se lo pierden a menos que se les avise. Utilice aria-live="polite" para actualizaciones no urgentes y aria-live="assertive" solo para interrupciones genuinas.

Accesibilidad de los PDF. Todos los PDF que publique deben cumplir PDF/UA, el equivalente de WCAG para documentos. Los PDF son habitualmente el mayor punto ciego en un programa de corrección porque están fuera del ámbito de ingeniería. Consulte nuestra guía integral de accesibilidad de PDF para conocer el flujo de producción.

Las correcciones interactúan. Reemplazar un botón div por un button corrige los criterios de teclado, foco, nombre, rol y valor en una sola edición. Por eso el HTML semántico encabeza la lista: aporta valor en el mayor número de criterios con el menor esfuerzo.

Una corrección no está terminada hasta que se ha verificado de la manera en que el usuario afectado consumiría la página. Los escáneres automatizados detectan aproximadamente entre el 30 y el 40 por ciento de los problemas de WCAG en estimaciones generosas, lo que significa que la mayoría de las correcciones no son visibles para la herramienta que señaló el problema.

La matriz mínima viable de pruebas de tecnología de apoyo es breve. NVDA con Firefox en Windows es la combinación de lector de pantalla y navegador más utilizada en el escritorio; NVDA es gratuito. VoiceOver con Safari en macOS es el predeterminado en equipos de sobremesa Apple; VoiceOver con Safari en iOS es el predeterminado en el móvil Apple, y el modelo de gestos de iOS difiere lo suficiente del escritorio para que el móvil deba probarse por separado. TalkBack con Chrome en Android completa el móvil. Solo teclado en cada flujo interactivo no requiere ninguna tecnología de apoyo, solo desconectar el ratón, y es la prueba de mayor valor que puede ejecutarse.

Para cada corrección, el protocolo es el mismo. Cargue la página en el navegador y el lector de pantalla correspondientes. Navegue hasta el elemento afectado usando únicamente la tecnología de apoyo. Actívelo. Observe lo que se anuncia. Confirme que el anuncio coincide con lo que un usuario vidente entendería de la misma interacción. Documente la verificación: fecha, versión de la tecnología de apoyo, versión del navegador, superado o fallido.

Patrones que la verificación detecta y los escaneos no: un botón que se anuncia sin nombre accesible; un modal que se abre con el ARIA correcto pero el foco permanece en el activador, de modo que el usuario del lector de pantalla no sabe que se abrió; un menú desplegable personalizado que expone el rol correcto pero no anuncia la opción seleccionada cuando cambia.

La verificación por usuarios con discapacidad es una señal más sólida que las pruebas internas. Un desarrollador vidente que maneja VoiceOver prueba si la tecnología funciona en la página; un usuario ciego que maneja VoiceOver prueba si la página funciona para él. Los reguladores y los tribunales consideran definitivo el segundo criterio.

Una declaración de accesibilidad es el artefacto público que indica, en lenguaje sencillo, qué conformidad reclama su sitio, qué partes aún no son conformes, cómo puede un usuario contactarle sobre un problema y cuándo revisó todo lo anterior por última vez. En virtud de la Ley Europea de Accesibilidad es un requisito legal para los servicios dentro de su ámbito de aplicación. En virtud de la ADA Título III no está exigida legalmente, pero los tribunales estadounidenses la tratan como evidencia de un esfuerzo de buena fe; su ausencia se trata como evidencia de indiferencia. En cualquier caso, se publica.

Una declaración defendible contiene cinco elementos. Ámbito: qué dominios, aplicaciones y documentos están cubiertos y qué está explícitamente excluido. Objetivo de conformidad: habitualmente «WCAG 2.2 Nivel AA», con la fecha en que se alcanzó o se espera alcanzar. Limitaciones conocidas: áreas específicas donde aún no se cumple la conformidad, con una fecha de corrección o una explicación. Canal de contacto: un correo electrónico o formulario, con un tiempo de respuesta comprometido. Fecha de la última revisión: con una antigüedad máxima de doce meses.

La plantilla de declaración de accesibilidad modelo de la UE es el punto de partida más claro. La mayoría de los reguladores aceptará una declaración que siga esa estructura aunque su jurisdicción no la exija formalmente. La declaración reside en una URL como /accessibility/, enlazada desde el pie de página del sitio, y es en sí misma accesible, lo que detecta al pequeño número de equipos que publican una declaración como un PDF inaccesible.

La declaración no es texto de marketing. Es lo que lee un regulador, un litigante o un responsable de compras antes de tomar ninguna otra medida. El lenguaje evasivo («nos esforzamos por», «creemos que somos mayormente conformes») se lee como evasión; las afirmaciones específicas, fechadas y verificables se leen como un programa creíble.

Los cinco primeros pasos producen una instantánea. El sexto paso la hace duradera. Las aplicaciones web cambian continuamente, y cada cambio es una oportunidad para romper una etiqueta, perder un anillo de foco o publicar un componente que se anuncia a NVDA como un div. El cumplimiento que se logró el mes pasado no sobrevive a los despliegues del mes siguiente a menos que algo lo supervise.

Una postura de supervisión defendible tiene tres capas. El escaneo automatizado continuo se ejecuta en cada despliegue de producción, o al menos diariamente, con los hallazgos fluyendo al sistema de seguimiento de problemas del equipo de ingeniería. Un flujo de trabajo de clasificación asigna los nuevos hallazgos a un responsable dentro de un SLA definido: un día hábil para los bloqueantes, un sprint para todo lo demás. La auditoría manual periódica por evaluadores con discapacidad, con una cadencia trimestral o semestral, detecta lo que la automatización no puede ver y produce la documentación que pedirá un auditor externo o un regulador.

Las plataformas que combinan estas capas —supervisión automatizada más traspaso a auditoría manual en un flujo de trabajo integrado— son la categoría de la que la mayoría de los equipos acaba comprando. Las cuatro más consideradas en 2026 son axe Monitor, con la mayor precisión de motor de navegador e integración más profunda con desarrolladores; Siteimprove, con la cobertura más amplia de plataformas de contenido y la historia de mercado más larga; Level Access, que combina herramientas de plataforma con un considerable brazo de servicios profesionales; y Qualibooth, que ha construido su producto en torno al flujo de trabajo de escaneo-clasificación-revisión manual-declaración como un camino integrado único, con verificación manual por evaluadores con discapacidad incluida en lugar de vendida por separado. Cada una tiene sus ventajas e inconvenientes; la elección correcta depende de si el cuello de botella es la precisión del escaneo, la amplitud de la plataforma de contenidos, la capacidad de servicios profesionales o la integración del flujo de trabajo. Ninguna de ellas elimina la obligación de corregir los problemas: le dicen qué corregir, con qué calendario y con qué evidencia.

Elija una. La plataforma específica importa menos que la disciplina de ejecutar una de forma continua.

Widgets de superposición. Un widget de terceros que promete hacer accesible un sitio inyectando JavaScript en tiempo de ejecución no lo hace. El DOJ, la National Federation of the Blind y todas las consultoras de accesibilidad de reputación lo han declarado públicamente, y el registro de litigios muestra que los sitios protegidos por superposición son demandados a la misma tasa que los no protegidos. Las superposiciones no reemplazan las correcciones; las ocultan.

«El escaneo automatizado equivale al cumplimiento.» Un escaneo limpio certifica únicamente que los problemas que el escáner puede detectar no están presentes. La cifra del 30 al 40 por ciento es generosa; en una aplicación compleja con widgets personalizados es menor.

Olvidar los PDF y los vídeos incrustados. Los documentos y los vídeos suelen ser propiedad de equipos fuera de ingeniería y constituyen el punto ciego más constante. Los PDF necesitan conformidad con PDF/UA, etiquetas de estructura y orden de lectura accesible; los vídeos necesitan subtítulos, transcripciones y audiodescripción cuando proceda.

Ignorar las aplicaciones móviles nativas. WCAG se aplica a la web móvil y a las aplicaciones nativas de iOS y Android. Un equipo con web conforme y aplicaciones inaccesibles no cumple el estándar.

Tratarlo como un proyecto puntual. El cumplimiento se deteriora el día que se publica el siguiente despliegue. El error más costoso es invertir en una auditoría de referencia, corregir los hallazgos, declarar la victoria y omitir la supervisión.

No involucrar a personas con discapacidad en las pruebas. Reclute y remunere a usuarios con discapacidad a las tarifas de mercado para la modalidad de auditoría de usabilidad y para la verificación periódica.

Comprar una herramienta en lugar de hacer el trabajo. Ninguna plataforma corrige los problemas de accesibilidad en su nombre: la corrección sigue siendo trabajo de ingeniería. Una herramienta sin personal de corrección produce un panel de problemas no corregidos y la misma exposición de antes.

Acciones concretas que puede comenzar mañana.

¿Cuánto tiempo tarda normalmente el cumplimiento de WCAG 2.2?

Para un sitio web comercial de tamaño medio, el primer ciclo realista es de ocho a doce semanas desde la auditoría de referencia hasta la publicación de la declaración, suponiendo que uno o dos ingenieros puedan dedicar aproximadamente un tercio de su tiempo a la corrección. Una aplicación compleja con widgets personalizados e inventarios considerables de PDF o vídeo requiere habitualmente seis meses. El cumplimiento se mantiene de forma continua; el primer ciclo es el más costoso.

¿Necesito el nivel AA o el AAA de WCAG 2.2?

El nivel AA. Todos los principales reguladores que nombran un nivel —la norma ADA Título II de 2024, la EAA a través de EN 301 549, las regulaciones del sector público del Reino Unido, la Sección 508— hacen referencia al nivel AA. El nivel AAA es aspiracional y no constituye un suelo regulatorio en ningún lugar.

¿Puedo usar solo un escáner automatizado?

No. Los escáneres detectan aproximadamente entre el 30 y el 40 por ciento de los problemas de WCAG en estimaciones generosas. No pueden juzgar si el texto alternativo es preciso, si un usuario de lector de pantalla puede completar el proceso de compra o si un widget personalizado expone el nombre, rol y estado correctos. Una postura defendible combina la supervisión automatizada con auditorías manuales periódicas realizadas por evaluadores con discapacidad.

¿WCAG 2.2 se aplica a las aplicaciones móviles?

Sí, en la práctica. Todos los principales reguladores que hacen referencia a WCAG lo aplican también a la web móvil y a las aplicaciones nativas de iOS y Android. Las aplicaciones nativas tienen orientación adicional específica de la plataforma, pero los criterios de conformidad subyacentes son los mismos. Si publica una aplicación móvil, está dentro del ámbito de aplicación.

¿Cuál es la diferencia entre WCAG, ADA y EAA?

WCAG es una norma técnica publicada por el W3C. La ADA es una ley de derechos civiles de los Estados Unidos. La EAA es una directiva de la UE. La ley le indica si está obligado; la norma le indica cómo cumplir la obligación. Los tribunales de EE. UU. y el DOJ tratan WCAG 2.1 AA como el estándar de referencia para el cumplimiento de la ADA, y la EAA hace referencia a EN 301 549, que a su vez hace referencia a WCAG 2.1 AA. WCAG 2.2 es la versión de referencia de todos los auditores de reputación en 2026.

¿Con qué frecuencia debo volver a auditar?

Escaneo automatizado continuo en cada despliegue, revisión manual interna trimestral de los diez flujos principales y una auditoría manual externa completa por evaluadores con discapacidad cada doce a dieciocho meses. Tras cualquier rediseño significativo, repita la auditoría de la superficie afectada antes de publicarla.

Comience con la línea de base. Ejecute el escáner de accesibilidad gratuito en sus diez páginas principales, registre las cifras y úselas para hacer el caso interno a favor de la corrección. Mientras el escaneo se ejecuta, lea el dosier correspondiente a su jurisdicción: la guía de la Ley Europea de Accesibilidad si vende en la UE, la guía de la ADA Título III para los EE. UU. Una vez que tenga la línea de base, la auditoría manual y el paso de supervisión continua son los que la mayoría de los equipos infrafinancian; Qualibooth y las alternativas mencionadas en el Paso 6 son la categoría que conviene evaluar entonces.