La accesibilidad web suena técnica y lejana, algo para grandes corporaciones con equipos de compliance. Pero tiene una dimensión muy concreta: si tu web no funciona bien para personas con alguna discapacidad visual, motora o cognitiva, estás excluyendo a una parte de tu mercado potencial. En Perú, el INEI estima que alrededor del 10% de la población tiene algún tipo de discapacidad. No es un grupo pequeño.

Y hay una razón adicional: muchas de las prácticas de accesibilidad también mejoran el SEO, la velocidad de carga y la experiencia general de todos los usuarios. No es un costo puro; es una inversión con retornos múltiples.

Qué son las WCAG y por qué deberías conocerlas

Las WCAG (Web Content Accessibility Guidelines) son las pautas internacionales de accesibilidad publicadas por el W3C, el consorcio que define los estándares de la web. La versión actual usada como referencia es la 2.1, aunque la 2.2 ya está publicada y la 3.0 está en desarrollo.

Las pautas se organizan en tres niveles de conformidad: A (mínimo), AA (estándar recomendado) y AAA (máximo, no siempre práctico). La mayoría de organizaciones apuntan al nivel AA como objetivo razonable. En varios países, el cumplimiento AA es obligatorio para sitios del sector público. En Perú no hay una ley específica que lo exija para el sector privado aún, pero la tendencia normativa global va en esa dirección.

Los cuatro principios base

Las WCAG se organizan bajo cuatro principios que el contenido web debe cumplir: perceptible, operable, comprensible y robusto. Cada uno tiene criterios concretos con nivel de conformidad asignado.

Perceptible

El contenido tiene que poder percibirse por los sentidos disponibles del usuario. El ejemplo más conocido: las imágenes necesitan texto alternativo (atributo alt) para que los lectores de pantalla puedan describirlas a personas con discapacidad visual. Pero hay más: los videos necesitan subtítulos, el contenido no debe depender solo del color para comunicar información.

Operable

Toda la funcionalidad debe poder operarse con teclado, no solo con ratón. Para usuarios con limitaciones motoras que no pueden usar el ratón, la navegación por teclado es esencial. Esto incluye menús desplegables, modales, formularios y carruseles.

Comprensible

El lenguaje debe ser claro y la navegación predecible. Los formularios tienen que indicar claramente qué campo está mal y por qué. Las páginas deben tener un idioma declarado en el HTML para que los lectores de pantalla pronuncien correctamente.

Robusto

El código HTML debe ser suficientemente limpio y semántico para que las tecnologías de apoyo (lectores de pantalla, ampliadores de pantalla) puedan interpretarlo correctamente. Esto no significa hacer webs aburridas, sino escribir HTML con los elementos correctos.

Qué revisar primero en tu web

Si empiezas desde cero con la accesibilidad, estos son los puntos de mayor impacto y menor complejidad:

• Contraste de color: el texto debe tener una relación de contraste mínima de 4.5:1 con el fondo para tamaño normal (nivel AA). Herramientas como WebAIM Contrast Checker lo verifican en segundos.
• Texto alternativo en imágenes: todas las imágenes que transmiten información deben tener un alt descriptivo. Las decorativas deben tener alt="" para que el lector de pantalla las ignore.
• Orden lógico de encabezados: h1, h2, h3 deben usarse como jerarquía de contenido, no por su tamaño visual. Un lector de pantalla navega el documento por encabezados.
• Formularios accesibles: cada campo de formulario debe tener un label asociado. Los mensajes de error deben ser específicos («El correo no tiene un formato válido») y no solo cambiar el color del borde.
• Navegación por teclado: prueba tu web usando solo Tab, Shift+Tab, Enter y las teclas de dirección. Si hay elementos que no puedes activar con teclado, hay un problema de accesibilidad.

Errores frecuentes en webs peruanas

El más común es el contraste insuficiente en textos grises claros sobre fondo blanco. Muchos diseñadores los usan para dar jerarquía visual, pero el gris #999999 sobre blanco no supera el mínimo de contraste para texto normal. Solución: usar tonos más oscuros como #767676 o simplemente diferenciar la jerarquía con tamaño, no con color.

El segundo error es usar imágenes de texto. Si el nombre de tu empresa o un titular importante está como imagen JPG en vez de texto HTML con CSS, los lectores de pantalla no lo pueden leer y Google tampoco. Es una mala práctica tanto para accesibilidad como para SEO.

El tercero es no declarar el idioma del documento. Una línea en el HTML: <html lang="es">. Si falta, el lector de pantalla puede pronunciar el español con acento en inglés, haciendo el contenido incomprensible para usuarios ciegos.

Herramientas para auditar accesibilidad

Tienes opciones gratuitas que cubren la mayoría de los errores automáticos detectable:

• WAVE (wave.webaim.org): extensión de navegador que señala errores de accesibilidad visualmente sobre la página.
• axe DevTools: extensión para Chrome que integra análisis en las herramientas de desarrollo.
• Lighthouse: incluido en Chrome DevTools, tiene una sección de accesibilidad con puntuación y recomendaciones.

Ojo: estas herramientas detectan automáticamente entre el 30% y el 40% de los problemas de accesibilidad. El resto requiere revisión manual. Una buena auditoría incluye navegar la web con solo el teclado y, si es posible, probarla con un lector de pantalla como NVDA (Windows, gratuito) o VoiceOver (Mac/iPhone, incluido).

Accesibilidad en WordPress

WordPress tiene un compromiso explícito con la accesibilidad desde la versión 3.0. Los temas del directorio oficial que llevan el tag «accessibility-ready» cumplen un conjunto básico de requisitos. Pero eso no significa que todo lo que construyas sobre ellos sea automáticamente accesible.

Los constructores como Elementor o Divi generan estructuras de HTML que a veces tienen problemas de accesibilidad. Vale la pena revisar con WAVE o axe cualquier página importante de tu web después de construirla.

Para proyectos donde la accesibilidad es un requisito desde el diseño (sector público, salud, educación), lo mejor es definirla como criterio de aceptación desde el inicio. Corregir accesibilidad después del diseño siempre cuesta más que integrarla desde el principio. En freelo.pe incorporamos estas revisiones en el proceso de diseño y desarrollo web.

El argumento de negocio

Más allá de la ética y el cumplimiento normativo, una web accesible tiene ventajas concretas. El SEO mejora porque Google valora la estructura semántica, los textos alternativos y el HTML limpio. La experiencia de usuario en condiciones adversas (luz solar directa, una mano ocupada, conexión lenta) también mejora. Y se amplía el mercado potencial a personas que de otra forma no podrían usar tu web.

No tienes que hacer todo a la vez. Empieza con el contraste, el texto alternativo y los formularios. Eso solo ya cubre una parte importante del nivel A y AA. El resto puede ir por fases.

Preguntas frecuentes

¿Las WCAG son obligatorias para las empresas privadas en Perú?

Actualmente no hay una ley peruana que obligue al sector privado a cumplir las WCAG. Sin embargo, la tendencia normativa global avanza hacia esa dirección, y varios países de la región ya tienen requerimientos para sitios públicos y privados. Aplicarlas hoy es una inversión en cumplimiento futuro y en experiencia de usuario.

¿Qué nivel WCAG debo apuntar para mi web?

El nivel AA es el estándar recomendado para la mayoría de webs. El nivel A es el mínimo absoluto y el AAA es muy exigente, con criterios que no siempre son prácticos de cumplir para todo el contenido. Apuntar a AA te pone en un estándar internacionalmente reconocido sin requerir un presupuesto extraordinario.

¿Una web accesible perjudica el diseño visual?

No necesariamente. El contraste adecuado, el HTML semántico y los formularios bien etiquetados no limitan la creatividad visual. Las restricciones reales son pocas: no usar solo el color para comunicar información y asegurar que el foco del teclado sea visible. Con buen criterio de diseño, estas restricciones son fáciles de integrar desde el principio.

¿Cómo puedo probar mi web con un lector de pantalla?

En Windows, NVDA es gratuito y ampliamente usado. En Mac e iPhone, VoiceOver viene incluido en el sistema. La combinación más usada en tests de accesibilidad es NVDA con Firefox o Chrome. Prueba navegar tu página principal sin ver la pantalla: solo escucha. Si algo es confuso o falta contexto, hay trabajo por hacer.

¿Los plugins de WordPress generan webs accesibles automáticamente?

No de forma automática. Constructores como Elementor o Divi pueden generar estructuras HTML con problemas de accesibilidad, como divs genéricos en lugar de elementos semánticos o modales que no son operables con teclado. Es necesario revisar las páginas con herramientas como WAVE o axe después de construirlas, independientemente del plugin usado.