Accesibilidad web no es solo cumplir con personas con discapacidad: es diseñar sitios que cualquier persona pueda usar en cualquier contexto, incluyendo el ejecutivo que abre tu landing en mobile con sol fuerte sobre la pantalla. En 2026 la presión regulatoria crece en sectores regulados peruanos (banca, salud, educación, entidades públicas) y los buscadores premian indirectamente sitios accesibles vía Core Web Vitals y semántica HTML. Esta guía explica WCAG 2.2 sin tecnicismos, qué nivel apuntar, los errores más comunes en sitios peruanos y cómo auditar el tuyo.
Qué es la accesibilidad web y por qué dejó de ser opcional
La accesibilidad web (a11y) es la práctica de diseñar y construir sitios que personas con cualquier capacidad puedan usar: visión limitada, motricidad reducida, audición disminuida, cognición distinta. La especificación de referencia internacional es WCAG (Web Content Accessibility Guidelines), publicada por el W3C; la versión vigente en 2026 es WCAG 2.2. Cumplir con WCAG ya no es solo un acto ético: para muchas empresas peruanas es presión regulatoria, requisito de licitaciones públicas, y palanca de SEO.
Implicaciones legales y reputacionales en Perú
Entidades del Estado peruano están obligadas a cumplir estándares de accesibilidad por la Ley 29973 y normas conexas. Empresas en sectores regulados (banca, salud, educación) reciben crecientemente requerimientos contractuales. Más allá de la ley, hay un costo reputacional: cuando un usuario con discapacidad reporta públicamente que no puede usar tu sitio, el daño es inmediato y difícil de reparar. El argumento «es opcional en privado» es cada vez más insostenible.
El argumento de negocio (mercado, SEO, conversión)
Tres beneficios cuantificables. Mercado: aproximadamente 10%–15% de la población tiene alguna discapacidad permanente; otro 30% experimenta limitaciones temporales. Sin accesibilidad, pierdes acceso a ese mercado. SEO: HTML semántico, alt texts, headings jerárquicos y contraste mejoran señales que Google usa, incluyendo Core Web Vitals. Conversión: formularios claros, contraste alto, navegación predictible benefician a todos los usuarios. Para entender el impacto en Core Web Vitals, ver la guía de SEO técnico y Core Web Vitals.
WCAG 2.2: niveles A, AA, AAA y a cuál apuntar
WCAG define tres niveles. Nivel A: mínimo legal, exigencias básicas (alt texts, no flashes peligrosos). Nivel AA: estándar de la industria y referencia para la mayoría de regulaciones; equilibrio entre exigencia y factibilidad. Nivel AAA: aspiracional para sitios con audiencias específicas (educación especial, salud); difícil para sitios de uso general. Para empresas peruanas medianas, AA es el objetivo realista y razonable. Cumplir AA suele cubrir 95% de requerimientos regulatorios y reputacionales.
Las 4 grandes áreas (perceptible, operable, comprensible, robusta)
WCAG organiza criterios bajo cuatro principios POUR. Perceptible (Perceivable): el usuario debe poder percibir la información (alt text para imágenes, captions para video, contraste suficiente). Operable: el usuario debe poder operar la interfaz (navegación por teclado, tiempo suficiente para leer, no triggers epilépticos). Comprensible (Understandable): la información debe ser entendible (idioma declarado, mensajes de error claros, navegación predictible). Robusta (Robust): el contenido debe funcionar con tecnologías asistivas (HTML válido, ARIA correcto, compatibilidad con lectores de pantalla).
Errores frecuentes que excluyen usuarios
Contraste y tipografía
Texto gris claro sobre blanco es la falla #1 en sitios «elegantes» en Perú. WCAG AA exige contraste 4,5:1 para texto normal y 3:1 para texto grande. Tipografía menor a 14px en cuerpo es difícil de leer en mobile con sol. Fixes simples: aumentar contraste a niveles WCAG, tipografía mínima 16px en cuerpo, line-height 1,5x mínimo, no usar solo color para transmitir información (rojo/verde para errores: añadir ícono o texto).
Formularios y mensajes de error
Formularios sin labels asociados son inaccesibles para lectores de pantalla. Errores que solo aparecen como íconos rojos sin texto son invisibles para muchos usuarios. Buenas prácticas: cada input con label visible y asociado por atributo for, mensajes de error que digan qué pasó y cómo arreglarlo (no solo «campo inválido»), validación que ocurre tras pérdida de foco, no en cada tecla.
Imágenes sin texto alternativo y videos sin captions
Imágenes informativas requieren alt text descriptivo (no «imagen1.png»). Imágenes decorativas requieren alt=»» para que lectores de pantalla las ignoren. Videos requieren captions (subtítulos sincronizados) y, para AAA, transcripción completa. Una empresa promedio peruana tiene ~30%–40% de imágenes sin alt text o con alt genérico; auditarlas y corregirlas es ganancia rápida.
Navegación por teclado y lectores de pantalla
Pruebe usar su sitio solo con teclado (Tab para avanzar, Shift+Tab para retroceder, Enter para activar). Si pierde el foco visible o no puede llegar a partes del sitio, falla accesibilidad básica. Lectores de pantalla (NVDA en Windows, VoiceOver en Mac, TalkBack en Android) leen el contenido en voz alta; HTML semántico bien hecho (h1, nav, main, aside, footer) los ayuda a navegar. Divs anidados sin estructura semántica los confunden.
Cómo auditar la accesibilidad de tu sitio (herramientas y pruebas con usuarios)
Auditoría en tres capas. Automatizada: Lighthouse (Chrome DevTools), WAVE, axe DevTools, Pa11y. Detecta 30%–50% de problemas. Manual con checklist: revisa contraste, navegación por teclado, alt texts, formularios, video. Detecta otro 30%–40%. Pruebas con usuarios reales: la única forma de detectar el 20%–30% restante; involucra a personas con discapacidad como testers (en Perú hay grupos como Sodis y Conadis que ayudan a coordinar). Las tres capas juntas son lo único que asegura cumplimiento real.
Accesibilidad + SEO + Core Web Vitals (cómo se refuerzan)
Las tres disciplinas se refuerzan mutuamente. HTML semántico es base de accesibilidad y de SEO. Velocidad de carga y Core Web Vitals afectan UX para todos. Buenas alt texts mejoran indexación de imágenes. Contraste y tipografía mejoran legibilidad y, por tanto, dwell time. Una empresa que invierte en accesibilidad típicamente mejora también su SEO técnico. Para la capa técnica del diseño, ver la guía de diseño web corporativo.
Hoja de ruta para empresas con sitios complejos
Para sitios con muchas páginas y años de deuda técnica, plan de 6 meses realista. Mes 1: auditoría completa + priorización. Mes 2–3: arreglos críticos (Nivel A) en home, páginas de servicio y conversión. Mes 4: extensión a páginas secundarias y blog. Mes 5: corrección de Nivel AA. Mes 6: pruebas con usuarios + validación final. Capacitar al equipo interno para mantener accesibilidad en nuevas páginas es clave; sin eso, en 12 meses regresas al punto de partida.
Niveles WCAG
| Nivel | Qué exige | Para quién |
|---|---|---|
| A | Mínimo legal: alt texts, no flashes peligrosos, navegación por teclado básica | Todos los sitios |
| AA | Estándar industria: contraste 4,5:1, captions, mensajes de error claros | Empresas medianas y reguladas |
| AAA | Aspiracional: contraste 7:1, lengua de señas, audio descripción | Sitios con audiencias específicas |
Tabla 1. Niveles WCAG y para quién aplica.
Errores frecuentes y solución
| Problema | Impacto | Cómo arreglarlo |
|---|---|---|
| Contraste insuficiente | Usuarios con visión limitada no leen | Aumentar a 4,5:1 mínimo |
| Imágenes sin alt text | Invisibles para lectores de pantalla | Alt descriptivo o alt=»» si decorativa |
| Formularios sin labels | Confusos con tecnología asistiva | Label asociado a cada input |
| Video sin captions | Excluye usuarios sordos | Captions sincronizados + transcripción |
| Navegación solo con mouse | Excluye usuarios con limitación motora | Probar todo con teclado |
| Divs sin semántica | Lectores de pantalla pierden estructura | Usar h1, nav, main, aside, footer |
Tabla 2. Errores frecuentes y su solución.
Herramientas de auditoría
| Herramienta | Qué detecta | Costo |
|---|---|---|
| Lighthouse (Chrome DevTools) | Auditoría básica integrada | Gratis |
| WAVE | Errores visuales con highlights | Gratis |
| axe DevTools | Auditoría profesional, integración CI/CD | Gratis / USD 99+ |
| Pa11y | CLI para auditorías automáticas | Gratis |
| Siteimprove | Monitoreo continuo enterprise | Custom |
| Tester con discapacidad | Detecta lo que herramientas no ven | Variable |
Tabla 3. Herramientas de auditoría de accesibilidad.
La fuente oficial de WCAG y la documentación más actualizada es W3C Web Accessibility Initiative (WAI), que mantiene las pautas, técnicas, ejemplos y casos de fallo organizados por criterio.
Preguntas frecuentes sobre accesibilidad web
¿Es obligatorio que mi web sea accesible?
Para entidades del Estado peruano, sí (Ley 29973). Para empresas reguladas (banca, salud, educación), creciente presión contractual. Para empresas privadas en general, no obligatorio por ley pero requisito de licitaciones, contratos con multinacionales y, cada vez más, expectativa social.
¿Qué nivel de WCAG debo cumplir?
Nivel AA es el estándar realista para empresas medianas peruanas. Cumplirlo cubre 95% de requerimientos regulatorios y reputacionales. Nivel A es mínimo de partida; AAA es aspiracional para sitios especializados.
¿La accesibilidad afecta mi SEO?
Indirectamente, sí. HTML semántico, alt texts, contraste y velocidad son señales que mejoran SEO. Una mejora seria de accesibilidad suele venir acompañada de mejoras en Core Web Vitals y dwell time. Ver guía de SEO técnico y Core Web Vitals.
¿Cuánto cuesta hacer accesible un sitio empresarial?
Depende del estado actual y del tamaño. Auditoría completa: USD 1.500–USD 5.000. Corrección de problemas críticos en sitio mediano: USD 3.000–USD 10.000. Refactor profundo: USD 10.000+. Mantenimiento continuo: USD 300–USD 1.000/mes para sitios con publicación frecuente.
¿Sirve un overlay/plugin «mágico»?
En general no. Los overlays prometen accesibilidad instantánea pero suelen empeorar la experiencia con tecnología asistiva. WAI y comunidad de a11y los desaconsejan. La accesibilidad real requiere intervención sobre el código y el contenido, no un script externo.
¿Cómo pruebo si mi web es accesible?
Tres capas: Lighthouse/WAVE/axe DevTools para auditoría automática (gratis, en 10 minutos detecta 30%–50% de problemas), checklist manual con teclado y contraste, pruebas con usuarios reales. Para integrar accesibilidad al diseño desde el día 1, ver la guía de diseño web corporativo.
Próximo paso: auditemos la accesibilidad de tu sitio
¿Tu sitio cumple con WCAG? Hagamos una auditoría de accesibilidad con apoyo del servicio de diseño web. Conversemos sobre tu proyecto.
