La accesibilidad WCAG dejó de ser un "extra" hace años. La Directiva Europea 2016/2102[1] ya está en vigor y el European Accessibility Act[2] se adopta de forma progresiva. Con ellas, cumplir WCAG 2.1[3] nivel AA pasó de ser una buena práctica a un requisito legal para las organizaciones que entran en su ámbito.

Sin embargo, la accesibilidad sigue teniendo fama de proyecto gigante e inabordable. Este artículo propone un camino pragmático para cubrir WCAG sin desesperarte.

Puntos clave

  • WCAG 2.1 nivel AA es el objetivo legal y técnico realista; AAA es opcional.

  • El 40% de los criterios se resuelve con HTML semántico bien escrito.

  • Para componentes complejos (modales, menús, tabs), usa librerías accesibles antes que ARIA artesanal.

  • Ninguna herramienta automatizada detecta más del 30-40% de los problemas; añade revisión manual con teclado y lector de pantalla.

  • Un equipo disciplinado llega a WCAG 2.1 AA en 2-3 meses con axe en CI, librerías accesibles y un checklist por release.

Los cuatro principios que vertebran WCAG

WCAG se articula alrededor de cuatro principios, recordados por el acrónimo POUR (Perceivable, Operable, Understandable, Robust). En español los llamamos:

  • Perceptible: el contenido tiene que poder percibirse por los sentidos disponibles del usuario.

  • Operable: la interfaz tiene que poder usarse con teclado, voz, conmutadores, no solo ratón.

  • Comprensible: tanto la información como el funcionamiento de la UI tienen que ser entendibles.

  • Robusto: el código tiene que ser interpretable por lectores de pantalla y otras tecnologías de asistencia presentes y futuras.

Cada principio se descompone en pautas, y cada pauta en criterios de éxito etiquetados con un nivel de conformidad (A, AA o AAA). El nivel AA es el objetivo práctico: incluye todo lo del nivel A y añade los criterios que cubren la inmensa mayoría de necesidades reales. El nivel AAA existe, pero como requisito general resulta inalcanzable sin sacrificar otras dimensiones.

Empezar leyendo los 50 criterios de nivel AA es, en efecto, abrumador. La buena noticia es que no tienes que resolverlos todos a la vez.

Un camino incremental en tres capas

En lugar de tratar WCAG como un check gigantesco, conviene organizarlo en tres capas que coinciden con tres tipos de trabajo distintos.

Capa 1: el HTML semántico

Aproximadamente el 40% de los criterios de WCAG se resuelven escribiendo HTML correctamente. Las reglas no negociables:

  • Usar <button> en vez de <div onclick>.

  • Poner <label> a cada <input>.

  • Respetar la jerarquía de encabezados (<h1> → <h2> → <h3>).

  • Asociar las tablas con <th scope="col">.

  • Añadir atributos alt a las imágenes significativas y alt="" a las decorativas.

Este trabajo no requiere librerías ni herramientas: requiere disciplina y una revisión sistemática del marcado existente. Es también la capa que más impacto tiene sobre usuarios de lectores de pantalla, navegación por teclado y modos de alto contraste. Si no haces nada más, haz esto.

Capa 2: el comportamiento con JavaScript

La segunda capa aparece cuando el HTML por sí solo no basta:

  • Menús desplegables.

  • Diálogos modales.

  • Pestañas.

  • Comboboxes personalizados.

Aquí entra la ARIA Authoring Practices Guide[4], que documenta patrones probados de interacción accesible para cada componente compuesto.

La regla de oro de ARIA es: no uses ARIA si puedes evitarlo. Un <button type="button"> nativo accesible es siempre preferible a un <div role="button" tabindex="0" aria-pressed="false"> artesanal. Pero cuando no queda más remedio, ARIA da el vocabulario para comunicar estados y roles al árbol de accesibilidad.

Componentes de librerías maduras resuelven gran parte de este trabajo con implementaciones probadas (gestión de foco, navegación por teclado, anuncios de lector de pantalla):

  • Radix UI[5] para React, headless y agnóstico de estilo.

  • Headless UI[6] de los autores de Tailwind, también headless.

  • React ARIA[7] de Adobe, primitivos de bajo nivel.

Si vienes de prototipar en Figma, esto encaja con la disciplina que describimos en Figma para prototipado colaborativo: el componente accesible nace en el design system, no en el último sprint.

Capa 3: el contenido

El tercer bloque sorprende a los equipos técnicos: WCAG tiene criterios sobre el contenido, no solo sobre el código. Los más habituales:

  • Contraste de color y legibilidad del texto.

  • Subtítulos de los vídeos y transcripciones de los audios.

  • Instrucciones que no dependen únicamente de color o forma.

  • Alternativas en texto para cualquier información transmitida visualmente.

Estos criterios requieren involucrar a diseñadores, redactores y equipos de producto, no solo a desarrollo. Como señalamos en la elección de palabras en tu aplicación, el lenguaje claro es parte de la accesibilidad: textos simples, frases cortas y terminología consistente benefician especialmente a usuarios con discapacidades cognitivas.

Herramientas prácticas

Ninguna herramienta automatizada puede detectar más allá del 30-40% de los problemas de accesibilidad (los expertos de Deque[8] han documentado ese techo), pero sí ayudan a cortar el trabajo manual a la mitad. Las tres a integrar desde el primer día:

  • axe de Deque[8]: motor de auditoría usado por docenas de herramientas. Existe como extensión de navegador, integración de Cypress/Playwright y acción de CI. Encuentra lo que cualquier auditor detectaría en su primera pasada.

  • WAVE de WebAIM[9]: ideal para auditorías visuales rápidas. Sobreimprime iconos sobre la página indicando problemas, lo que hace sencilla la comunicación con equipos no técnicos.

  • Lighthouse de Chrome: integrado en las DevTools, cubre un subconjunto de las reglas de axe. Útil como guardarraíl continuo.

A esto añade una revisión manual con teclado (navegar la aplicación entera sin ratón) y una pasada con un lector de pantalla (NVDA en Windows, VoiceOver en macOS) al menos una vez por iteración. Ningún test automático sustituye este paso. La lógica es la misma que aplicamos en tests de contrato con Pact: la herramienta automática no es el único nivel de verificación, es el primero.

Flujo de trabajo recomendado

Para equipos que parten de cero, el orden que menos fricciones genera es:

  • Auditoría inicial con axe o WAVE sobre las 5-10 vistas más críticas. Clasifica los hallazgos por criterio de éxito WCAG.

  • Tres sprints de HTML semántico: arreglar labels, headings, alt-text, foco visible, contraste. Sin diseño nuevo, sin código nuevo: solo corrección.

  • Incorporación de librerías accesibles para los componentes compuestos que implementa el equipo: diálogos, menús, tabs.

  • Integración de axe en CI (regla: bloquear merge si aparecen errores de nivel crítico). Esto evita retrocesos.

  • Checklist manual como la de A11y Project[10] antes de cada release, complementada con la prueba de teclado + lector de pantalla.

Con disciplina, este camino lleva a cumplir WCAG 2.1 AA en 2-3 meses. No es rápido, pero tampoco es el proyecto infinito que parece desde fuera. La clave está en la repetición disciplinada, el mismo principio que recomendamos en prompt engineering maduro: pequeños pasos verificables, no grandes saltos.

Errores frecuentes que conviene evitar

Al acompañar proyectos en esta transición, hay cuatro patrones problemáticos que aparecen una y otra vez:

  • Tratar la accesibilidad como una auditoría puntual en lugar de una práctica continua. Sin CI, los errores vuelven a aparecer en cada sprint.

  • Confundir "pasa Lighthouse 100" con "es accesible". Lighthouse no detecta ni la mitad de los problemas reales; ayuda a bajar el nivel del ruido, no garantiza calidad.

  • Añadir aria-label a todo por si acaso. Un aria-label redundante puede hacer que el lector de pantalla anuncie información dos veces. El "ARIA cuanto menos mejor" también aplica.

  • Probar solo con un lector de pantalla. NVDA, JAWS y VoiceOver interpretan algunos patrones de forma distinta. Si tu público objetivo es amplio, prueba con al menos dos.

La accesibilidad conecta con el pensamiento de diseño: es una competencia transversal del producto, no un chequeo final.

Conclusión

WCAG 2.1 AA es alcanzable si se ataca por capas: primero el HTML semántico, después el comportamiento dinámico, después el contenido. Con axe en CI, una librería accesible para los componentes complejos y un checklist manual por release, llegas al cumplimiento sin necesidad de grandes reestructuraciones.

Fuentes:

  1. W3C/WAI: WCAG 2.1 Quick Reference[3]
  2. Deque: axe Accessibility Testing Engine[8]
  3. WebAIM: WAVE Web Accessibility Evaluation Tool[9]
  4. A11y Project: Accessibility Checklist[10]
  5. Comision Europea: Directiva 2016/2102 sobre accesibilidad de sitios web[1]

Preguntas frecuentes

¿Basta con que Lighthouse dé 100 en accesibilidad para cumplir WCAG?

No. Ninguna herramienta automatizada detecta más del 30-40 % de los problemas de accesibilidad; Lighthouse cubre solo un subconjunto de las reglas de axe y sirve como guardarraíl continuo, no como garantía. Añade una revisión manual con teclado, navegando la aplicación entera sin ratón. Súmale una pasada con un lector de pantalla como NVDA en Windows o VoiceOver en macOS al menos una vez por iteración.

¿Cuánto tiempo lleva a un equipo llegar a WCAG 2.1 nivel AA?

Con disciplina, llegar cuesta 2-3 meses. El orden con menos fricción empieza por una auditoría con axe o WAVE sobre las 5-10 vistas más críticas. Siguen tres sprints de HTML semántico corrigiendo labels, encabezados, alt-text, foco visible y contraste, y después librerías accesibles para los componentes compuestos. El último paso es axe en CI bloqueando el merge ante errores críticos, más un checklist manual antes de cada release.

¿Debo escribir ARIA a mano para modales, menús y pestañas?

Mejor no: la regla de oro es no usar ARIA si puedes evitarlo, y un elemento button nativo siempre es preferible a un div con role="button" y tabindex="0" artesanal. Para componentes compuestos, librerías maduras como Radix UI, Headless UI o React ARIA de Adobe ya resuelven la gestión de foco, la navegación por teclado y los anuncios del lector de pantalla. Añadir aria-label a todo por si acaso puede hacer que el lector anuncie la información dos veces.

Fuentes

  1. Directiva Europea 2016/2102
  2. European Accessibility Act
  3. WCAG 2.1
  4. ARIA Authoring Practices Guide
  5. Radix UI
  6. Headless UI
  7. React ARIA
  8. Deque
  9. WAVE de WebAIM
  10. la de A11y Project