Mas de mil millones de personas en todo el mundo viven con alguna forma de discapacidad. Eso es aproximadamente el 15 % de la poblacion mundial. Entre ellas hay personas ciegas o con baja vision, personas sordas o con dificultades auditivas, personas con discapacidades motrices, diferencias cognitivas o condiciones temporales como un brazo roto o una migrana.
Cuando construimos sitios web sin considerar estas realidades, no solo hacemos las cosas inconvenientes. Estamos excluyendo a personas del acceso a informacion, servicios y oportunidades que otros dan por sentado. La accesibilidad no es una funcionalidad. Es una responsabilidad.
Que significa la accesibilidad web
La accesibilidad web significa disenar y desarrollar sitios web para que las personas con discapacidades puedan percibirlos, comprenderlos, navegar por ellos e interactuar con ellos. Tambien significa que puedan contribuir a la web.
Esto va mas alla de los lectores de pantalla. La accesibilidad abarca:
- Visual: ceguera, baja vision, daltonismo
- Auditiva: sordera, dificultades auditivas
- Motriz: control motor fino limitado, temblores, paralisis
- Cognitiva: dislexia, TDAH, dificultades de memoria, discapacidades de aprendizaje
- Temporal y situacional: una muneca rota, luz solar intensa en la pantalla, un entorno ruidoso, internet lento
La idea clave es que el diseno accesible beneficia a todos. Los subtitulos ayudan en un lugar ruidoso. El alto contraste ayuda bajo luz intensa. La navegacion por teclado ayuda a los usuarios avanzados. La escritura clara ayuda a los hablantes no nativos. La accesibilidad no es un modo especial — es buen diseno.
El estandar WCAG
Las Pautas de Accesibilidad para el Contenido Web (WCAG) son el estandar internacional para la accesibilidad web, publicado por el W3C. La version actual es WCAG 2.2, organizada en torno a cuatro principios conocidos por el acronimo POUR:
Perceptible (Perceivable)
La informacion debe presentarse de formas que todos los usuarios puedan percibir.
- Alternativas de texto: cada imagen necesita un atributo
altque describa su contenido. Las imagenes decorativas usanalt="". - Subtitulos y transcripciones: el contenido de video necesita subtitulos; el contenido de audio necesita transcripciones.
- Estructura adaptable: el contenido debe tener sentido cuando se eliminan los estilos. Usa HTML semantico (
<h1>,<nav>,<main>,<article>), no solo estilos visuales. - Contenido distinguible: contraste de color suficiente, texto redimensionable, ninguna informacion transmitida solo por color.
Operable (Operable)
Los usuarios deben poder operar la interfaz.
- Accesible por teclado: cada elemento interactivo debe ser alcanzable y utilizable solo con el teclado. Sin trampas de raton.
- Tiempo suficiente: si el contenido tiene limites de tiempo, los usuarios deben poder ampliarlos o desactivarlos.
- Sin desencadenantes de convulsiones: evita contenido que parpadee mas de tres veces por segundo.
- Navegable: titulos de pagina claros, estructura logica de encabezados, enlaces de navegacion rapida, indicadores de foco visibles.
Comprensible (Understandable)
El contenido y la interfaz deben ser comprensibles.
- Texto legible: especifica el idioma de la pagina (atributo
lang). Usa un lenguaje claro y sencillo cuando sea posible. - Comportamiento predecible: la navegacion debe ser consistente. Las paginas no deben cambiar de contexto inesperadamente.
- Asistencia en la entrada: etiqueta los campos de formulario claramente. Proporciona mensajes de error utiles que expliquen que salio mal y como solucionarlo.
Robusto (Robust)
El contenido debe ser suficientemente robusto para funcionar con tecnologias actuales y futuras.
- HTML valido: marcado semantico correcto que las tecnologias de asistencia puedan interpretar de forma fiable.
- Nombre, rol, valor: los componentes personalizados deben exponer su proposito a las APIs de accesibilidad (mediante ARIA cuando sea necesario).
Niveles de conformidad
WCAG define tres niveles:
| Nivel | Significado | Ejemplo |
|---|---|---|
| A | Accesibilidad minima | Las imagenes tienen texto alternativo, las paginas tienen titulos |
| AA | Objetivo estandar para la mayoria de sitios web | Relacion de contraste de color de al menos 4,5:1 para texto normal |
| AAA | Nivel mas alto, no siempre alcanzable | Relacion de contraste de 7:1, lengua de senas para todos los videos |
La mayoria de las legislaciones en todo el mundo exigen el cumplimiento del Nivel AA. Este es el nivel al que debes aspirar.
Barreras comunes y como solucionarlas
Texto alternativo faltante en imagenes
El problema: los usuarios de lectores de pantalla escuchan "imagen" o nada en absoluto.
La solucion: agrega texto alt descriptivo a cada imagen informativa. Para imagenes decorativas, usa alt="" para que los lectores de pantalla las omitan.
<!-- Bien -->
<img
src="chart.png"
alt="Bar chart showing a 40% increase in sales from January to June 2025"
/>
<!-- Decorativa -->
<img src="divider.svg" alt="" />
Contraste de color insuficiente
El problema: las personas con baja vision o daltonismo no pueden leer el texto.
La solucion: asegura una relacion de contraste minima de 4,5:1 para texto normal y 3:1 para texto grande (18px+ o 14px en negrita). Usa una herramienta de verificacion de contraste para comprobar tus combinaciones de colores.
Puedes verificar el contraste de tus colores ahora mismo con nuestro Verificador de contraste. Muestra los resultados WCAG AA y AAA al instante.
Etiquetas de formulario faltantes
El problema: los usuarios de lectores de pantalla no saben para que es un campo de formulario.
La solucion: cada entrada necesita un elemento <label> visible vinculado mediante el atributo for.
<!-- Bien -->
<label for="email">Direccion de correo electronico</label>
<input type="email" id="email" name="email" />
<!-- Mal: el marcador de posicion no es una etiqueta -->
<input type="email" placeholder="Correo electronico" />
Sin navegacion por teclado
El problema: los usuarios que no pueden usar un raton quedan bloqueados.
La solucion: usa elementos HTML nativos (<button>, <a>, <select>) que son accesibles por teclado de forma predeterminada. Si construyes componentes personalizados, asegurate de que sean enfocables y respondan a eventos de teclado. Nunca elimines los contornos de foco sin proporcionar una alternativa.
Estructura de pagina faltante
El problema: los usuarios de lectores de pantalla no pueden navegar eficientemente.
La solucion: usa HTML semantico. Un <h1> por pagina, jerarquia logica de encabezados (sin saltar niveles), landmarks (<nav>, <main>, <footer>).
Reproduccion automatica de medios
El problema: el audio inesperado interrumpe a los usuarios de lectores de pantalla. La reproduccion automatica de video puede provocar convulsiones o angustia.
La solucion: nunca reproduzcas audio automaticamente. Si el video se reproduce automaticamente, asegurate de que no tenga audio de forma predeterminada y proporciona controles de pausa.
El color no es suficiente
Nunca confies solo en el color para transmitir informacion. Considera:
- Un campo de formulario con borde rojo para errores tambien necesita un icono de error o un mensaje de texto
- Un grafico con lineas de colores tambien necesita patrones, etiquetas o una leyenda
- Un enlace en el texto corrido necesita un subrayado u otra senal visual, no solo un cambio de color
Aproximadamente el 8 % de los hombres y el 0,5 % de las mujeres tienen alguna forma de deficiencia en la vision del color. Disenar teniendo esto en cuenta no es un caso marginal — es inclusion basica.
Probar la accesibilidad
Pruebas automatizadas
Las herramientas automatizadas detectan aproximadamente el 30-40 % de los problemas de accesibilidad. Son un buen primer paso, no una solucion completa.
- axe DevTools (extension del navegador) — escanea una pagina e informa violaciones WCAG
- Lighthouse (integrado en Chrome DevTools) — incluye una auditoria de accesibilidad
- WAVE (herramienta basada en web) — superposicion visual que muestra problemas
Pruebas manuales
Muchos problemas de accesibilidad requieren juicio humano:
- Pruebas de teclado: desconecta tu raton y navega todo tu sitio con Tab, Enter, Escape y las teclas de flecha. Puedes llegar a todo? Es logico el orden del foco?
- Pruebas con lector de pantalla: prueba VoiceOver (Mac), NVDA (Windows, gratuito) o TalkBack (Android). Tiene sentido el contenido cuando se lee en voz alta?
- Pruebas de zoom: amplfa tu navegador al 200 %. Sigue funcionando el diseno? Se recorta o superpone algun contenido?
- Movimiento reducido: activa "reducir movimiento" en la configuracion de tu sistema operativo. Las animaciones respetan esta preferencia?
Pruebas con usuarios
Los comentarios mas valiosos provienen de personas que realmente usan tecnologias de asistencia en su vida diaria. Si tu presupuesto lo permite, incluye a personas con discapacidades en tu proceso de prueba.
La accesibilidad es un espectro, no una casilla de verificacion
La accesibilidad no es un proyecto unico con una linea de meta. Es una practica continua. Los sitios web cambian, se agrega contenido y pueden aparecer nuevas barreras con cada actualizacion.
El objetivo no es la perfeccion. El objetivo es la mejora continua y el cuidado genuino por las personas que usan lo que construyes. Comienza con los cambios de mayor impacto — contraste de color, texto alternativo, navegacion por teclado, etiquetas de formulario — y construye a partir de ahi.
Cada barrera que eliminas es una puerta que abres.
Lista de verificacion rapida
- Todas las imagenes tienen texto
altsignificativo (oalt=""si son decorativas) - El contraste de color cumple con WCAG AA (4,5:1 para texto, 3:1 para texto grande)
- Todos los campos de formulario tienen etiquetas visibles
- El sitio es completamente navegable por teclado
- Los encabezados siguen una jerarquia logica
- Los indicadores de foco son visibles
- El idioma de la pagina esta definido (atributo
langen<html>) - Ninguna informacion se transmite solo por color
- Los videos tienen subtitulos
- Las animaciones respetan
prefers-reduced-motion