Introducción
Aproximadamente el 15% de la población mundial tiene algún tipo de discapacidad que afecta cómo usa el software (OMS). Si tu aplicación no es accesible, estás excluyendo a ese porcentaje de tu audiencia — sin haberlo decidido conscientemente.
La accesibilidad web no es un requisito de nicho ni un checkbox de cumplimiento normativo. Es un criterio de calidad de software. Y como la mayoría de los criterios de calidad, es mucho más barato incorporarlo desde el diseño que corregirlo cuando ya está en producción.
¿Qué es WCAG?
WCAG son las siglas de Web Content Accessibility Guidelines — las pautas internacionales para hacer el contenido web accesible a personas con distintas capacidades. Las publica el W3C (World Wide Web Consortium) y se actualizan periódicamente.
Las versiones más relevantes en 2026:
- WCAG 2.1: la versión más adoptada. Añadió criterios para dispositivos móviles, usuarios con discapacidades cognitivas y visión baja respecto a versiones anteriores
- WCAG 2.2: la versión más reciente (2023). Añadió criterios adicionales sobre interacción con teclado, autenticación accesible y controles de interfaz
- WCAG 3.0: en desarrollo. Cambiará la estructura de criterios de forma significativa, pero todavía no está finalizada
La mayoría de las organizaciones tiene como objetivo de cumplimiento el nivel AA de WCAG 2.1, que es el nivel requerido por la mayoría de las regulaciones y el que equilibra accesibilidad real con factibilidad de implementación.
¿Cómo se organiza WCAG?
WCAG se organiza en torno a 4 principios, cada uno con pautas y criterios de éxito específicos:
| Principio | Qué significa | Ejemplos de criterios |
|---|---|---|
| Perceptible | La información y los componentes de la interfaz deben presentarse de forma que los usuarios puedan percibirlos | Texto alternativo en imágenes, subtítulos en videos, contraste mínimo de color |
| Operable | Los componentes de la interfaz y la navegación deben ser operables | Navegación completa por teclado, tiempo suficiente para completar tareas, sin contenido que provoque convulsiones |
| Comprensible | La información y el funcionamiento de la interfaz deben ser comprensibles | Idioma de la página definido, mensajes de error descriptivos, comportamiento predecible |
| Robusto | El contenido debe ser suficientemente robusto como para interpretarse por una amplia variedad de agentes de usuario, incluidas las tecnologías de asistencia | HTML semántico correcto, compatible con lectores de pantalla actuales |
¿Quiénes se benefician de la accesibilidad web?
La respuesta obvia son los usuarios con discapacidad. Pero el diseño accesible beneficia a más usuarios de los que se suele asumir:
- Usuarios con discapacidad visual: ceguera total, visión baja, daltonismo — dependen de lectores de pantalla, zoom y contraste suficiente
- Usuarios con discapacidad auditiva: necesitan subtítulos en contenido de audio/video
- Usuarios con discapacidades motoras: navegan con teclado, switches o software de control por voz — no pueden usar el ratón
- Usuarios con discapacidades cognitivas: se benefician de lenguaje claro, instrucciones simples y diseño consistente
- Usuarios en contextos adversos: usar el teléfono con un brazo ocupado, leer en luz solar directa, conexión lenta — las mismas soluciones que ayudan a usuarios con discapacidad ayudan en estos contextos
- Usuarios con tecnologías más antiguas: el HTML semántico correcto que beneficia a los lectores de pantalla también mejora la compatibilidad con navegadores y dispositivos más antiguos
Las mejoras de accesibilidad tienen un efecto universal: lo que hace el software más fácil de usar para alguien con discapacidad, generalmente lo hace más fácil de usar para todos.
¿Cómo se hace una auditoría de accesibilidad web?
Una auditoría de accesibilidad web completa combina herramientas automatizadas y revisión manual, porque ninguna de las dos por sí sola es suficiente.
Evaluación automatizada
Las herramientas automatizadas verifican criterios que tienen una respuesta binaria — la imagen tiene texto alternativo o no lo tiene, el contraste es suficiente o no lo es. Las más usadas: Axe, WAVE, Lighthouse (integrado en Chrome DevTools). Estas herramientas pueden detectar aproximadamente el 30–40% de los problemas de accesibilidad de forma automatizada.
Revisión manual con tecnologías asistivas
El 60–70% de los problemas de accesibilidad requieren revisión manual con las herramientas que usan los usuarios reales:
- Lectores de pantalla: NVDA y JAWS en Windows, VoiceOver en macOS y iOS, TalkBack en Android. Verificar que el lector de pantalla anuncia correctamente la información y que el flujo de navegación tiene sentido sin ver la pantalla
- Navegación por teclado: completar todos los flujos críticos sin usar el ratón. Verificar que el foco visible es claro en todo momento y que el orden de tabulación es lógico
- Zoom al 400%: verificar que el contenido sigue siendo funcional cuando el usuario amplía al 400% sin scroll horizontal
Informe y plan de corrección
El resultado de la auditoría es un informe que clasifica los problemas por nivel de conformidad WCAG (A, AA, AAA) y por impacto en el usuario. El plan de corrección prioriza por criticidad — no todos los problemas tienen el mismo impacto.
¿Cuál es el costo de no tener accesibilidad en producción?
Hay cuatro tipos de costo:
- Exclusión de usuarios: el porcentaje de usuarios que no puede usar la aplicación correctamente — con impacto directo en la audiencia alcanzable y, en modelos B2C, en el mercado potencial
- Riesgo legal: en Europa (directiva de accesibilidad de la UE), España (RD 1112/2018), Chile (Ley 20.422) y otros mercados, la accesibilidad web es un requisito legal para ciertos tipos de organizaciones. El incumplimiento puede generar sanciones
- Costo de corrección tardía: corregir problemas de accesibilidad en un sistema ya construido es más caro que diseñarlos accesibles desde el inicio — especialmente si implica cambios estructurales en el HTML o el diseño de interacción
- Deuda de calidad: un sistema inaccesible tiene problemas de HTML semántico, navegación por teclado y manejo de estado que también afectan a otros aspectos de calidad como SEO y compatibilidad con distintos navegadores
¿Cómo empezar si el sistema actual no tiene accesibilidad?
El enfoque más práctico para sistemas ya en producción sin historial de accesibilidad:
- Paso 1: Auditoría inicial para entender el estado actual — cuántos problemas hay, de qué nivel de criticidad, en qué partes del sistema
- Paso 2: Correcciones prioritarias — problemas de nivel A primero (los más básicos), luego AA. No intentar alcanzar AAA completo desde el inicio
- Paso 3: Incorporar accesibilidad en el proceso de desarrollo — criterios de aceptación accesibles, revisiones de accesibilidad en code review, tests automatizados en el pipeline
- Paso 4: Revisión periódica — la accesibilidad no es un estado que se alcanza y se mantiene solo. Cada nuevo componente o funcionalidad puede introducir regresiones
Para sistemas nuevos, la forma más eficiente es incorporar los criterios de accesibilidad en el diseño desde el inicio. El mismo tiempo que cuesta añadir accesibilidad a un componente diseñado sin considerarla puede ser diez veces mayor que diseñarlo accesible desde el principio.