Accesibilidad web: cómo hacer tu página inclusiva en Perú

Hace unos años, casi nadie en el Perú hablaba de accesibilidad web. Si alguien preguntaba si tu página era usable por una persona ciega o por alguien con movilidad limitada en las manos, la respuesta promedio era una mirada en blanco. Hoy, con la Ley 29973 vigente, la fiscalización empezando a apretar y una población de personas con discapacidad que pasa del millón y medio, el tema ya no es opcional. Es legal, es ético y, además, mejora el SEO.

En este artículo te voy a contar cómo aplicar accesibilidad web real en una página peruana sin morir en el intento. Sin teoría innecesaria, con las cosas que de verdad mueven la aguja y con los errores que veo todas las semanas cuando audito sitios de empresas, municipalidades y entidades del sector público.

Qué es accesibilidad web y por qué importa en Perú

Accesibilidad web es diseñar y desarrollar tu sitio para que cualquier persona pueda usarlo, incluyendo a quienes tienen discapacidad visual, auditiva, motriz o cognitiva. No es ponerle un botón gigante de subir letra. Tampoco es colgar un widget de accesibilidad y olvidarse. Es revisar contraste, semántica del HTML, navegación por teclado, descripciones de imagen, formularios con etiquetas y muchas otras cosas que se hacen una sola vez bien y se mantienen para siempre.

En el Perú la Ley 29973, Ley General de la Persona con Discapacidad, obliga a las entidades públicas a tener sitios web accesibles. El CONADIS ha publicado lineamientos basados en las pautas internacionales WCAG. Si tu organización es pública, ya estás dentro del alcance. Si eres una empresa privada, no estás obligado por ley directa, pero sí por la realidad: alrededor de uno de cada diez peruanos tiene alguna discapacidad, y esa cifra es mucho más alta si sumamos personas adultas mayores con presbicia, baja visión o problemas motores leves.

Y hay un detalle adicional que casi nadie te cuenta: Google premia las páginas accesibles. Los criterios técnicos de WCAG se solapan en buena parte con lo que Google considera buena experiencia de usuario. Una web accesible suele ser una web más rápida, mejor estructurada y con mejor SEO. Dos pájaros de un tiro.

Los cuatro principios POUR explicados sin tecnicismos

WCAG, que es el estándar global de accesibilidad, se organiza alrededor de cuatro principios conocidos como POUR por sus siglas en inglés. Te los traduzco sin academicismos.

Perceivable (perceptible)

Toda la información que pongas en la página tiene que poder ser percibida de alguna forma por el usuario. Si publicas una imagen con texto importante, ese texto también tiene que estar disponible para alguien que no ve la imagen. Si subes un video, necesitas subtítulos para quien no escucha. Si usas color para indicar algo, no puede ser la única señal porque hay personas con daltonismo.

Operable (operable)

Cualquiera tiene que poder navegar e interactuar con tu sitio sin importar el dispositivo de entrada que use. Eso significa que todo lo que se hace con mouse también se tiene que poder hacer con teclado. Nada de menús que solo abren con hover, nada de modales que no se cierran con Escape, nada de formularios donde no puedes saltar de campo en campo con Tab.

Understandable (comprensible)

El contenido y las interfaces tienen que ser entendibles. Lenguaje claro, instrucciones explícitas en los formularios, mensajes de error que digan qué falló y cómo arreglarlo. No basta con un genérico de tipo error: tiene que decir el correo que ingresaste no tiene formato válido.

Robust (robusto)

El código tiene que ser limpio y estandarizado para que distintas tecnologías asistivas, como lectores de pantalla y reconocedores de voz, lo interpreten bien. Un HTML semántico, con etiquetas usadas para lo que fueron creadas, te resuelve buena parte de esto.

Nivel AA: el objetivo realista para una web peruana

WCAG tiene tres niveles: A, AA y AAA. El nivel A es el mínimo absoluto y se queda corto. El nivel AAA es ideal pero técnicamente difícil de mantener en sitios con mucho contenido. El nivel AA es el estándar de referencia mundial, el que recomiendan los organismos internacionales y el que la mayoría de regulaciones exige cuando exige algo.

Si tu meta es WCAG 2.1 AA, vas por buen camino. WCAG 2.2 ya salió y añade algunas pautas, pero el grueso del trabajo es el mismo. Te voy a contar las que en mi experiencia auditando sitios peruanos son las que más impacto tienen.

Contraste de color: la regla que casi nadie cumple

WCAG 2.1 AA exige un contraste mínimo de 4.5 a 1 entre texto y fondo para texto de tamaño normal, y 3 a 1 para texto grande (a partir de 18 puntos en regular o 14 puntos en negrita). Esa relación se mide con la fórmula de luminancia y existen calculadoras gratuitas que te dan el número en segundos.

El error más común que veo en webs peruanas es texto gris claro sobre fondo blanco. Queda elegante en la maqueta del diseñador, pero un adulto mayor con presbicia simplemente no lo lee. Otro clásico es el texto blanco sobre fotos sin oscurecimiento previo, donde la legibilidad depende del píxel exacto. Y un tercero recurrente es usar el color de marca corporativo, generalmente un azul o un rojo medio, como color de enlace sobre fondo blanco, cuando no llega al 4.5 a 1.

La solución es probar todos los textos con una herramienta de contraste antes de aprobar el diseño. Si no cumple, oscurece el texto o aclara el fondo, no hay vuelta. Y el botón principal de llamada a la acción es donde menos vas a querer escatimar contraste.

Navegación con teclado: prueba tu propia web

Acá te propongo un experimento que vas a hacer ahora mismo. Abre tu página web, ponla en una pestaña, y suelta el mouse. Solo usa la tecla Tab para avanzar, Shift más Tab para retroceder, Enter para activar enlaces y botones, y las flechas para moverte dentro de elementos. ¿Puedes navegar por todo el sitio? ¿Llegar al menú? ¿Llenar el formulario de contacto? ¿Cerrar un modal que se abrió?

El 90% de las webs peruanas que pruebo se rompen en algún punto. Lo más típico es que el foco visible (ese contorno azul que indica dónde estás) se haya eliminado por CSS porque al diseñador no le gustaba. Sin foco visible, una persona que navega con teclado está literalmente perdida en tu sitio. Otra falla común es que los menús desplegables solo abran con hover, lo cual deja afuera al teclado y también a usuarios de pantalla táctil que tocan el menú padre y no entienden por qué no pasa nada.

La regla práctica: si funciona con mouse, debe funcionar con teclado. Punto.

Lectores de pantalla y ARIA: hablar el idioma de la asistencia

Los lectores de pantalla como NVDA, JAWS o el VoiceOver de Apple convierten en voz lo que aparece en pantalla. Para que entiendan bien tu web, el HTML tiene que estar bien escrito y, cuando algo no se puede expresar con HTML puro, se usan atributos ARIA.

Las prácticas concretas que más impacto tienen son: poner una etiqueta alt descriptiva a cada imagen relevante (las decorativas van con alt vacío, no se omite el atributo), usar etiquetas label asociadas a cada campo de formulario, marcar el menú principal con la etiqueta nav, usar h1 una sola vez por página y respetar la jerarquía de h2, h3 sin saltarse niveles, y poner aria-label a botones que solo tienen iconos (como una lupa o una equis).

Un menú hamburguesa típico en móvil debería tener algo como aria-label igual a abrir menú y aria-expanded que cambie entre true y false cuando se abre y se cierra. Sin eso, un lector de pantalla solo dice botón y la persona no sabe qué hace.

Formularios accesibles: donde se cae la mayoría

Los formularios son el punto crítico de la accesibilidad porque ahí se completan transacciones reales: una compra, una cita médica, una postulación a un trabajo, un reclamo. Si tu formulario no es accesible, estás dejando fuera a un porcentaje real de personas.

Cada campo necesita una etiqueta visible, no solo un placeholder que desaparece cuando empiezas a escribir. Los mensajes de error tienen que aparecer cerca del campo, ser descriptivos, y estar asociados al campo por aria-describedby para que el lector de pantalla los lea cuando navegues hasta ahí. Los campos obligatorios se marcan con asterisco visible y con el atributo required, no solo con el asterisco.

El captcha es otro gran problema. Si pones un reCAPTCHA visual sin alternativa, estás filtrando usuarios con discapacidad visual. La solución moderna es reCAPTCHA v3 o hCaptcha invisible, que no exige interacción y funciona en segundo plano.

Errores frecuentes en webs peruanas

Después de auditar decenas de sitios públicos y privados en el Perú, los errores se repiten. Te los listo para que los revises rápido.

Sliders automáticos en la home que cambian cada cuatro segundos. Una persona con discapacidad cognitiva o con baja visión no alcanza a leer antes de que se vaya. Si tienes que poner slider, agrega botones de pausa y avance manual.

Documentos PDF colgados sin alternativa accesible. Muchas municipalidades publican comunicados como imagen exportada a PDF. Para un lector de pantalla, eso es una caja negra. La solución es publicar también en HTML o generar PDFs etiquetados correctamente.

Videos sin subtítulos en español. Los subtítulos automáticos de YouTube en español son aceptables pero no perfectos. Para contenido institucional, conviene revisar y corregir.

Widgets de accesibilidad que prometen arreglar todo. Esos overlays que se ven como un botón con un muñequito en la esquina. La comunidad internacional de accesibilidad ha demostrado, demanda tras demanda, que no resuelven el problema y a veces lo empeoran. La accesibilidad se hace en el código, no con un parche encima.

Cómo auditar tu web sin gastar nada

Antes de contratar a un consultor, puedes hacer una primera revisión gratuita con herramientas estándar. WAVE de WebAIM te marca errores de accesibilidad directamente sobre tu página. Lighthouse, que viene integrado en Chrome, te da un puntaje y una lista de problemas. Axe DevTools es la extensión más usada profesionalmente y también tiene versión gratuita.

Lo que esas herramientas detectan es alrededor del 30% al 40% de los problemas reales. El resto se descubre con pruebas manuales: navegar con teclado, probar con un lector de pantalla, revisar contraste con WebAIM Contrast Checker. Si tu web es crítica, idealmente sumas pruebas con usuarios reales con distintas discapacidades.

Costo de implementar accesibilidad en una web peruana

Si parte desde cero, una web nueva diseñada con accesibilidad desde el inicio cuesta entre 10% y 20% más que una web sin esas consideraciones. Es decir, si tu web corporativa estándar costaba S/4.000, con accesibilidad bien hecha se va a S/4.500 a S/4.800.

Adaptar una web existente es más caro. Una auditoría completa parte desde S/1.500. La implementación de los hallazgos puede ir desde S/2.000 en sitios pequeños hasta S/20.000 o más en plataformas grandes. Por eso conviene incluir accesibilidad desde el diseño y no como remiendo.

Preguntas frecuentes sobre accesibilidad web en Perú

¿Mi empresa privada está obligada por ley a tener una web accesible en el Perú?

La Ley 29973 obliga directamente a las entidades públicas a tener sitios accesibles. Para el sector privado no hay obligación explícita aún, pero el Código de Protección y Defensa del Consumidor exige información clara y accesible a todo proveedor, y eso incluye la web. Además, hay tendencia regulatoria internacional a extender la obligación al sector privado, por lo que conviene adelantarse.

¿Qué nivel de WCAG debo apuntar para cumplir bien?

El nivel AA de WCAG 2.1 es el estándar de referencia mundial. Es lo que aplican casi todas las regulaciones serias y lo que técnicamente es alcanzable y sostenible. WCAG 2.2 ya está vigente y añade algunas pautas, pero apuntar a 2.1 AA cubre la enorme mayoría del trabajo.

¿Cuál es el contraste mínimo que debo usar para los textos de mi web?

Una relación de 4.5 a 1 entre texto y fondo para texto de tamaño normal, y 3 a 1 para texto grande, considerando grande a partir de 18 puntos en regular o 14 puntos en negrita. Para componentes gráficos y elementos de interfaz, el mínimo es 3 a 1.

¿Los widgets de accesibilidad que se instalan con un script realmente funcionan?

No. Los overlays prometen mucho pero en la práctica generan problemas y han sido objeto de demandas en Estados Unidos por incumplir accesibilidad real. Lo correcto es trabajar accesibilidad directamente en el código y en el diseño del sitio.

¿Puedo evaluar la accesibilidad de mi web sin contratar a un especialista?

Sí, hasta cierto punto. Herramientas como WAVE, Lighthouse y Axe te dan una primera lectura automatizada que detecta entre el 30% y el 40% de los problemas. Las pruebas manuales con teclado y con lector de pantalla suman bastante. Para certificar cumplimiento serio, conviene un especialista.

¿Cuánto encarece poner accesibilidad a una web desde el inicio?

Entre 10% y 20% sobre el costo base. Una web corporativa de S/4.000 termina en S/4.500 a S/4.800. Si lo haces como remiendo después, sale mucho más caro: una auditoría parte desde S/1.500 y la implementación puede pasar fácil de S/2.000 según el alcance.

¿Las imágenes decorativas también necesitan texto alternativo?

No con texto descriptivo, pero sí con el atributo alt vacío. Eso le indica al lector de pantalla que la imagen es decorativa y debe saltársela. Si omites el atributo, el lector puede leer la ruta del archivo, lo que es una mala experiencia.

¿Cómo hago un menú accesible si quiero que tenga submenús?

Los submenús deben abrirse con clic o con Enter al recibir foco con teclado, no solo con hover. El botón padre necesita aria-expanded que cambie de true a false, y debe ser posible cerrar el submenú con la tecla Escape. Eso permite que tanto usuarios de teclado como de lectores de pantalla naveguen sin trabarse.

¿Los PDF que cuelgo en mi web también deben ser accesibles?

Sí. Un PDF accesible tiene etiquetas estructurales, orden de lectura correcto y texto reconocible, no es una imagen escaneada. Si publicas mucho en PDF, conviene generar los documentos directamente desde Word o InDesign con accesibilidad activada, no exportar imágenes.

¿Qué pasa con los videos? ¿Basta con los subtítulos automáticos de YouTube?

Para contenido informal puede alcanzar, pero los subtítulos automáticos en español tienen errores de transcripción. Para contenido institucional o legal, conviene revisar y editar los subtítulos. Adicionalmente, los videos con información visual relevante deben tener audiodescripción para personas con discapacidad visual.