Accesibilidad web: cubrir WCAG sin desesperarte
Índice de contenidos
Actualizado: 2026-05-03
La accesibilidad WCAG dejó de ser un “extra” hace años. Con la entrada en vigor de la Directiva Europea 2016/2102[1] y la progresiva adopción del European Accessibility Act[2], cumplir WCAG 2.1[3] nivel AA pasó de ser una buena práctica a un requisito legal para muchas organizaciones. Sin embargo, muchos equipos siguen enfrentando la accesibilidad como un 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 en muchos casos es inalcanzable sin sacrificar otras dimensiones del producto.
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
alta las imágenes significativas yalt=""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 este 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.
Este camino, ejecutado con disciplina, lleva a la mayoría de aplicaciones a cumplir WCAG 2.1 AA en 2-3 meses. No es rápido, pero tampoco es el proyecto infinito que muchos temen. La clave es 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-labela todo por si acaso. Unaria-labelredundante 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.
Más en general, 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, la mayoría de equipos llega al cumplimiento sin necesidad de grandes reestructuraciones.
