WCAG explicado sin jerga técnica

Introducción

Para muchas personas, el primer encuentro con WCAG no resulta especialmente sencillo.

Al abrir el estándar aparecen rápidamente principios, pautas, criterios de conformidad, niveles de conformidad, técnicas, excepciones, definiciones y referencias a otros documentos. La información es útil, pero sin un modelo mental que permita entender cómo encajan todas esas piezas, WCAG puede parecer una enorme lista técnica que solo deberían comprender los especialistas en accesibilidad.

Esa no es la forma más útil de abordarlo.

En esencia, WCAG proporciona una manera estructurada de identificar barreras de accesibilidad y definir resultados que pueden evaluarse de forma consistente. Ayuda a diseñadores, desarrolladores, equipos de contenido, testers y organizaciones a pasar de un objetivo amplio como “hacer accesible este sitio web” a preguntas más concretas sobre si las personas pueden percibir la información, operar los controles, comprender lo que está ocurriendo y utilizar el producto con diferentes tecnologías.

Las siglas WCAG corresponden a Web Content Accessibility Guidelines, o Pautas de Accesibilidad para el Contenido Web, pero entender el nombre es solo el principio. La pregunta más importante es cómo se organiza el estándar y qué intenta conseguir realmente.

Este artículo se centra en WCAG 2.2, la versión más reciente de WCAG 2 recomendada por W3C para el trabajo actual de accesibilidad. En lugar de recorrer decenas de requisitos individuales, veremos la estructura que hay detrás de ellos: los cuatro principios, el papel de los criterios de conformidad, el significado de A, AA y AAA, qué cambió en WCAG 2.2 y por qué la conformidad es importante sin ser lo mismo que una experiencia de usuario perfecta.

Si estás comenzando con este tema, nuestra introducción a la accesibilidad web ofrece un contexto útil antes de entrar en el estándar.

¿Qué significa WCAG?

WCAG significa Web Content Accessibility Guidelines, o Pautas de Accesibilidad para el Contenido Web.

Es un estándar internacional de accesibilidad web desarrollado a través del World Wide Web Consortium, o W3C. Se aplica al contenido web y a las experiencias digitales, y establece requisitos destinados a hacerlas más accesibles para las personas con discapacidad.

WCAG no es un software, una herramienta de pruebas automáticas ni una certificación que W3C conceda a los sitios web. Tampoco es, por sí mismo, una ley universal. Distintos países y organizaciones pueden hacer referencia a WCAG en legislación, procesos de contratación, contratos o políticas internas, pero el estándar en sí es un marco técnico.

Esta distinción importa porque a veces se habla de WCAG como si fuera una insignia que un sitio web posee o no posee. En la práctica, el estándar resulta mucho más útil cuando se entiende como un lenguaje común para identificar barreras y definir qué debe cumplirse para satisfacer determinados requisitos de accesibilidad.

Un requisito sobre acceso mediante teclado, por ejemplo, no existe porque el teclado sea preferible al ratón. Existe porque algunas personas no pueden utilizar un dispositivo apuntador y aun así deben poder llegar a los controles y operarlos.

Un requisito sobre alternativas textuales no consiste en añadir metadatos porque sí. Existe porque determinada información visual puede necesitar comunicarse de otra forma.

La redacción técnica describe una expectativa verificable. La barrera de accesibilidad explica por qué esa expectativa existe.

¿Quién crea WCAG?

WCAG se desarrolla a través del World Wide Web Consortium (W3C) y de su Web Accessibility Initiative (WAI).

En este trabajo participa el Accessibility Guidelines Working Group, con personas y organizaciones que aportan experiencia en accesibilidad, estándares, tecnología, investigación y necesidades relacionadas con la discapacidad.

Este proceso colaborativo es importante porque la accesibilidad web no pertenece a un navegador, una empresa tecnológica, un gobierno o una profesión en particular. La web se utiliza internacionalmente, a través de muchas tecnologías y por personas con formas muy diferentes de percibir e interactuar con el contenido digital.

Por eso, WCAG busca definir requisitos de una manera que no dependa demasiado de una implementación o un producto concreto. El estándar describe los resultados que deben alcanzarse, mientras que documentos de apoyo como Understanding WCAG y Techniques for WCAG ofrecen explicaciones adicionales sobre cómo pueden cumplirse esos resultados.

Esa separación es una de las razones por las que el estándar puede seguir siendo relevante aunque las tecnologías cambien.

Los cuatro principios: POUR

WCAG 2.2 contiene 13 pautas organizadas bajo cuatro principios: Perceptible, Operable, Comprensible y Robusto.

En inglés suelen recordarse mediante el acrónimo POUR: Perceivable, Operable, Understandable y Robust.

Los principios son deliberadamente amplios. No indican exactamente cómo debe construirse un formulario, diseñarse un menú de navegación o programarse un modal. En su lugar, describen cuatro condiciones fundamentales que una experiencia digital accesible debe ser capaz de cumplir.

Perceptible

La primera pregunta es sencilla: ¿pueden las personas acceder a la información?

El contenido no puede ser útil si se presenta de una forma que una persona no puede percibir.

Para alguien que no puede ver una imagen, eso puede significar ofrecer una alternativa textual adecuada. Para alguien que no puede oír un audio, la información hablada importante puede necesitar subtítulos u otro equivalente en texto. Para una persona con baja visión, el texto y los controles pueden necesitar un contraste suficiente y la capacidad de adaptarse cuando se amplía el contenido.

Perceptible no significa que todas las personas deban experimentar la información exactamente de la misma manera. Significa que la información importante no debería depender de una única forma sensorial de presentación cuando se necesita otra alternativa.

Operable

La siguiente pregunta es: ¿pueden las personas interactuar con la experiencia?

Un control que parece perfectamente claro pero al que no se puede llegar sin un ratón puede resultar inaccesible para alguien que navega con teclado. Un objetivo táctil pequeño que exige movimientos muy precisos puede crear una barrera para una persona con movilidad limitada. Una interacción que se mueve o cambia demasiado rápido puede resultar difícil o imposible para alguien que necesita más tiempo.

Operable abarca la mecánica de la interacción: navegación, acceso mediante teclado, tiempos, foco, gestos, movimiento y las formas en que los usuarios controlan lo que ocurre en la página.

La idea central es que la interfaz no debería asumir un único método de entrada.

Comprensible

La accesibilidad también depende de si las personas pueden comprender la información y el comportamiento de la interfaz.

Las instrucciones claras, las etiquetas significativas, una navegación predecible, los mensajes de error útiles y los patrones de interacción consistentes contribuyen a este principio.

Una interfaz puede exponer técnicamente todos sus controles a las tecnologías de asistencia y aun así resultar difícil de utilizar si el lenguaje es confuso o si el producto se comporta de forma impredecible.

Comprensible nos recuerda que la accesibilidad no consiste únicamente en que la información y los controles estén disponibles. Las personas también necesitan suficiente claridad para entender qué significan y qué ocurrirá cuando interactúen con ellos.

Robusto

Robusto suele ser el menos intuitivo de los cuatro principios.

Una forma útil de entenderlo es preguntarse: ¿pueden diferentes tecnologías interpretar la experiencia de manera fiable?

El contenido web no se consume únicamente a través de un navegador en un único dispositivo. Las personas pueden utilizar diferentes navegadores, sistemas operativos, lectores de pantalla, herramientas de ampliación, entrada por voz u otras tecnologías de asistencia.

Por eso, la estructura y la semántica subyacentes de una página deben comunicar la información de formas que esas tecnologías puedan comprender.

La robustez tiene que ver con la compatibilidad. Una interfaz no debería funcionar únicamente porque una combinación concreta de navegador y dispositivo logre interpretarla correctamente hoy.

WCAG organiza la accesibilidad alrededor de cuatro principios: perceptible, operable, comprensible y robusto.

¿Qué son los criterios de conformidad?

Los cuatro principios facilitan la comprensión de WCAG, pero son demasiado amplios para determinar por sí solos la conformidad.

Aquí es donde entran en juego los criterios de conformidad.

La estructura puede entenderse en tres niveles:

Principios → Pautas → Criterios de conformidad

Los principios proporcionan la base general. Las pautas describen objetivos importantes de accesibilidad dentro de cada principio. Los criterios de conformidad definen resultados específicos que pueden evaluarse.

Por ejemplo, afirmar que el contenido debe ser perceptible nos da una dirección, pero todavía no ofrece información suficiente para determinar si una página concreta cumple o no cumple. Los criterios de conformidad convierten esa dirección en requisitos que pueden evaluarse sobre contenido real.

W3C describe los criterios de conformidad como enunciados verificables. Para una pieza de contenido determinada, el objetivo es poder determinar con un alto nivel de confianza si el criterio se satisface.

La palabra verificable es importante, pero no significa verificable automáticamente.

Algunos problemas de accesibilidad pueden detectarse mediante software. Otros requieren criterio humano. Una herramienta puede detectar que una imagen tiene un atributo alt, por ejemplo, pero no puede determinar de forma fiable en todas las situaciones si el texto alternativo comunica realmente la información que aporta la imagen.

Lo mismo ocurre con muchas cuestiones relacionadas con la interacción y el contenido.

Por eso, una evaluación de accesibilidad suele combinar pruebas automatizadas, comprobaciones manuales y pruebas realizadas por personas que comprenden cómo interactúan con la web los usuarios con discapacidad.

WCAG proporciona a los equipos un estándar con el que evaluar un producto. No elimina la necesidad de criterio profesional.

WCAG convierte principios amplios de accesibilidad en criterios específicos que los equipos pueden evaluar de forma consistente.

A, AA y AAA explicados

Los criterios de conformidad de WCAG se asignan a tres niveles: A, AA y AAA.

Estos niveles se interpretan con frecuencia como si fueran una simple puntuación de calidad, como si A significara una accesibilidad deficiente, AA una buena accesibilidad y AAA una accesibilidad perfecta.

El modelo no funciona así.

Nivel A es el nivel mínimo de conformidad. Una página conforme con el Nivel A satisface todos los criterios de conformidad aplicables de Nivel A.

Nivel AA incluye tanto los criterios de Nivel A como los de Nivel AA.

Nivel AAA incluye los criterios de Nivel A, Nivel AA y Nivel AAA.

Por tanto, los niveles representan conjuntos acumulativos de requisitos, no calificaciones sobre la calidad visual o experiencial de un sitio web.

Muchas organizaciones utilizan WCAG 2.2 Nivel AA como objetivo práctico. Esta es también la razón por la que tantas búsquedas y requisitos de accesibilidad hacen referencia a “WCAG AA”.

Pero el Nivel AA no debería interpretarse como “completamente accesible”, del mismo modo que AAA no debería entenderse como “accesibilidad perfecta”.

W3C señala expresamente que no se recomienda exigir la conformidad de Nivel AAA como política general para sitios completos, porque algunos tipos de contenido no pueden satisfacer todos los criterios de conformidad AAA.

Los equipos también pueden ir más allá de los requisitos mínimos del nivel de conformidad que tienen como objetivo. Un producto que aspire a AA puede satisfacer determinados criterios AAA cuando sean relevantes y alcanzables.

La pregunta útil no es “¿cuál es la insignia más alta que podemos reclamar?”, sino “¿qué barreras de accesibilidad estamos evitando y qué nivel de conformidad podemos demostrar realmente?”.

Por qué importa WCAG 2.2

WCAG ha evolucionado a medida que han evolucionado la web y nuestra comprensión de la accesibilidad digital.

WCAG 2.2 se convirtió en una Recomendación de W3C en octubre de 2023 y añadió nueve criterios de conformidad respecto de WCAG 2.1.

Esas incorporaciones abordan aspectos como la visibilidad del foco, alternativas a las acciones de arrastrar, tamaño mínimo de los objetivos, acceso coherente a la ayuda, evitar la introducción repetida de datos y la autenticación accesible.

Los detalles varían, pero varias de estas incorporaciones reflejan una preocupación más amplia por barreras que aparecen en patrones de interacción modernos.

Por ejemplo, arrastrar puede resultar sencillo para alguien que utiliza un ratón o una pantalla táctil con movimientos precisos, pero difícil o imposible para una persona que no puede realizar ese gesto. Los procesos de autenticación que dependen demasiado de la memoria o de pruebas cognitivas pueden crear barreras incluso cuando el resto de la interfaz es accesible. Los objetivos pequeños pueden hacer la interacción innecesariamente difícil para personas con destreza limitada.

WCAG 2.2 no convierte las versiones anteriores en irrelevantes. W3C publica WCAG 2.0, 2.1 y 2.2 como estándares estables, y los requisitos de las versiones anteriores se mantienen en gran medida.

Existe un cambio estructural destacable: el criterio de conformidad 4.1.1 Parsing quedó obsoleto y fue eliminado de WCAG 2.2.

Sin embargo, para nuevos trabajos de accesibilidad en 2026, WCAG 2.2 es el punto de referencia más sensato porque representa la versión más reciente de WCAG 2 e incluye requisitos introducidos después de WCAG 2.1.

¿Cumplir WCAG significa que un sitio web es perfectamente accesible?

No.

La conformidad con WCAG es extremadamente importante, pero tiene un significado específico.

Para ser conforme con WCAG, el contenido debe satisfacer los criterios de conformidad aplicables al nivel declarado, junto con los demás requisitos de conformidad. Esto proporciona a las organizaciones un estándar claro y consistente con el que evaluar un producto digital.

Pero una evaluación de conformidad satisfactoria no garantiza que todas las personas con cualquier discapacidad tengan una experiencia excelente.

El propio W3C reconoce esta distinción. Su documentación explica que un contenido puede satisfacer todos los criterios de conformidad y aun así no ser usable por personas con una amplia variedad de discapacidades. Por eso recomienda realizar pruebas de usabilidad además de las pruebas funcionales de conformidad e incluir a personas con discapacidad en las pruebas con usuarios.

Esto está estrechamente relacionado con la diferencia que exploramos en Accesibilidad, usabilidad y experiencia de usuario: ¿cuál es la diferencia?.

Un formulario puede satisfacer los criterios técnicos relevantes y aun así utilizar un lenguaje innecesariamente confuso. Un flujo puede admitir navegación mediante teclado pero exigir demasiado esfuerzo cognitivo. Una estructura de navegación puede ser semánticamente correcta y, sin embargo, resultar mucho más compleja de lo que necesitan los usuarios.

WCAG ayuda a definir una base esencial de accesibilidad. No debería convertirse en una razón para dejar de preguntarnos si el producto funciona realmente bien para las personas.

¿Y qué ocurre con WCAG 3?

WCAG 3 es la próxima generación de las pautas de accesibilidad de W3C, pero es importante no tratarla como un sustituto terminado de WCAG 2.2.

El 3 de marzo de 2026, W3C publicó una versión actualizada del Working Draft de WCAG 3. El borrador explora un enfoque más amplio de las pautas de accesibilidad y una estructura y modelo de conformidad diferentes de los de WCAG 2.

Pero sigue siendo un Working Draft.

Eso significa que su contenido continúa en desarrollo y puede cambiar de forma significativa antes de que el estándar esté terminado.

Para las organizaciones que planifican trabajo de accesibilidad en 2026, la consecuencia práctica es sencilla: no hay que esperar a WCAG 3 para mejorar la accesibilidad.

WCAG 2.2 sigue siendo el estándar actual con el que trabajar. La propia documentación introductoria de W3C sobre WCAG 3 orienta a las organizaciones hacia el cumplimiento de WCAG 2.2 mientras WCAG 3 continúa desarrollándose.

Vale la pena seguir WCAG 3 porque indica hacia dónde evolucionan los estándares de accesibilidad. Pero todavía no es el marco que los equipos deberían utilizar como sustituto de la conformidad con WCAG 2.2.

¿Por dónde debería empezar una organización?

El primer paso no consiste en memorizar todos los criterios de conformidad.

Consiste en comprender suficientemente bien la estructura como para que el estándar deje de parecer una colección de reglas técnicas sin relación entre sí.

Empieza por los cuatro principios. Proporcionan una forma útil de pensar en las barreras a través del diseño, el contenido, la interacción y la implementación.

Después, familiarízate con los criterios de conformidad relevantes para el trabajo que realiza tu equipo. La How to Meet WCAG 2: Quick Reference de W3C resulta especialmente útil porque permite filtrar y explorar los requisitos sin tener que leer toda la especificación de principio a fin.

En un sitio web existente, comienza identificando dónde aparecen actualmente las barreras. Las herramientas automatizadas pueden ayudar a detectar algunos problemas rápidamente, pero las pruebas manuales son esenciales para aspectos como la interacción mediante teclado, el orden del foco, el zoom, la calidad del contenido y el comportamiento de los componentes.

Para trabajos nuevos, la mejor estrategia es prevenir los problemas antes de que se propaguen. Los requisitos de accesibilidad pueden influir en las decisiones sobre color, patrones de interacción, estructura del contenido, componentes reutilizables y criterios de aceptación mientras esas decisiones todavía son fáciles de cambiar. Exploramos este enfoque en Por qué la accesibilidad debe formar parte del diseño web desde el primer día.

Sobre todo, evita convertir WCAG en responsabilidad de un único especialista al final del proyecto.

Los diseñadores necesitan comprender las implicaciones de accesibilidad de las decisiones visuales y de interacción. Los desarrolladores necesitan comprender la semántica, el comportamiento con teclado, el foco y la compatibilidad con tecnologías de asistencia. Los equipos de contenido deben pensar en la estructura, el lenguaje, las alternativas y las instrucciones. Los responsables de producto deben hacer que la accesibilidad forme parte de lo que se espera que el producto consiga.

WCAG se vuelve mucho más útil cuando los equipos dejan de verla como una lista que tienen que aprobar y empiezan a utilizarla como un marco compartido para encontrar y prevenir barreras.

El estándar es técnico porque la accesibilidad necesita requisitos que puedan evaluarse de forma consistente. Pero el propósito que hay detrás de esos requisitos no es técnico en absoluto.

Es asegurarse de que más personas puedan utilizar realmente los productos y servicios digitales de los que dependen.