¿Qué es la accesibilidad web? WCAG y diseño inclusivo explicados
La accesibilidad web consiste en construir sitios y apps para que las personas con discapacidad puedan usarlos, ya sean personas ciegas que usan un lector de pantalla, personas que no pueden usar el ratón, personas con baja visión o daltonismo, personas sordas o personas con discapacidad cognitiva o de aprendizaje. En la práctica se reduce a cosas como textos alternativos para las imágenes, suficiente contraste de color, formularios con etiquetas adecuadas y que todo funcione solo con el teclado. La norma internacional es WCAG, las Pautas de Accesibilidad para el Contenido Web del W3C.
La accesibilidad suele abreviarse como a11y: «a», luego once letras y «y».
Por qué la accesibilidad importa cuando creas con IA
Los creadores con IA son buenos generando apps que parecen correctas. La accesibilidad depende sobre todo de lo que no se ve en una captura de pantalla: si un botón es realmente un botón, si un campo tiene una etiqueta que un lector de pantalla puede anunciar, si puedes llegar al menú con la tecla Tab.
Por eso conviene preguntar:
- Es fácil pasarlo por alto. Un desplegable con estilo personalizado puede verse perfecto y ser imposible de usar sin ratón. No lo notarás a menos que lo pruebes.
- Es más barato hacerlo bien desde el principio. Pedir componentes accesibles desde el primer prompt cuesta casi nada. Adaptar una app terminada implica tocar cada pantalla.
- Ayuda a todo el mundo. Los subtítulos ayudan a quien está en un lugar ruidoso, un buen contraste ayuda a quien usa el móvil a pleno sol, y las etiquetas claras ayudan a todos a rellenar formularios más rápido.
- Se solapa con el SEO. Los encabezados bien estructurados, los enlaces descriptivos y el texto alternativo también ayudan a los buscadores a entender tus páginas; consulta SEO para sitios web creados con IA.
- Puede ser obligatorio. Según dónde operes y a quién sirvas, la accesibilidad puede ser una obligación legal.
Una analogía cotidiana
Piensa en la entrada de un edificio.
Los escalones sirven bien a mucha gente. Una rampa sirve a las personas en silla de ruedas y también a los padres con cochecitos, a los repartidores con carros y a los viajeros con maletas. Las puertas automáticas, las señales claras, el braille en los botones del ascensor y una buena iluminación eliminan una barrera para alguien.
La accesibilidad web es la misma idea para los espacios digitales: las rampas, las señales y los pasamanos de tu app. Y, como en un edificio, es mucho más fácil incluir una rampa en los planos que añadirla después de que el hormigón haya fraguado.
WCAG en pocas palabras
WCAG lo publica la Iniciativa de Accesibilidad Web del W3C. La versión actual es WCAG 2.2, publicada por primera vez en octubre de 2023. Es retrocompatible: el contenido que cumple WCAG 2.2 también cumple 2.1 y 2.0, y el W3C recomienda usar la versión más reciente. WCAG 2.2 también está aprobada como norma internacional, ISO/IEC 40500:2025. Una WCAG 3 muy distinta está en desarrollo como borrador temprano, no como norma terminada.
WCAG se organiza en cuatro principios, que se recuerdan como POUR:
| Principio | Significado | Ejemplos |
|---|---|---|
| Perceptible | Las personas pueden captar el contenido con los sentidos que usan | Texto alternativo para imágenes, subtítulos en vídeos, contraste suficiente |
| Operable | Las personas pueden usar los controles y navegar | Acceso por teclado, sin límites de tiempo que no se puedan ampliar, foco visible |
| Comprensible | El contenido y el comportamiento tienen sentido | Etiquetas claras, mensajes de error útiles, navegación coherente |
| Robusto | Funciona con distintos navegadores y tecnologías de asistencia | Elementos HTML adecuados, nombres y roles correctos para los controles |
Cada pauta tiene criterios de éxito comprobables en tres niveles:
- Nivel A: el mínimo. No cumplirlo bloquea por completo a algunas personas.
- Nivel AA: el objetivo estándar, y el nivel al que apuntan la mayoría de leyes y políticas.
- Nivel AAA: el nivel más alto. Conviene aspirar a él en algunas partes, pero el W3C no recomienda exigirlo a sitios enteros, porque algunos contenidos no pueden cumplirlo.
WCAG 2.2 añadió nueve criterios de éxito a la 2.1, entre ellos Tamaño del objetivo (mínimo) en el nivel AA (los objetivos pulsables deben tener, en general, al menos 24 por 24 píxeles CSS, con excepciones) y Autenticación accesible (mínimo), que limita los pasos de inicio de sesión que dependen de la memoria o de acertijos, como tener que volver a escribir una contraseña sin permitir pegarla. También eliminó el antiguo criterio de «Análisis», por obsoleto.
Un ejemplo práctico: un formulario de registro
Este es un formulario de registro que podría generar una IA, y lo que encuentra una revisión de accesibilidad:
| Problema | A quién afecta | Solución |
|---|---|---|
| Los campos usan texto de marcador («Correo») en lugar de etiquetas | Usuarios de lector de pantalla; cualquiera que olvide qué era el campo al empezar a escribir | Un <label> visible conectado a cada campo |
| Texto gris claro sobre blanco, muy por debajo de 4,5:1 de contraste | Personas con baja visión, cualquiera al aire libre | Texto más oscuro que cumpla el contraste de 4,5:1 |
| Los errores se muestran solo con un borde rojo | Usuarios daltónicos, usuarios de lector de pantalla | Un mensaje de texto junto al campo, anunciado a los lectores de pantalla |
«Registrarse» es un <div> con estilo, no un <button> | Los usuarios de teclado y de lector de pantalla no pueden activarlo | Usar un elemento <button> real |
| No hay contorno visible al recorrer los campos con Tab | Los usuarios de teclado pierden la referencia de dónde están | Un estilo de foco claro |
| La imagen del logotipo no tiene texto alternativo | Usuarios de lector de pantalla oyen un nombre de archivo | Texto alternativo como «Acme Bookings» |
Ninguna de estas soluciones cambia mucho el aspecto del formulario. Todas cambian si algunas personas pueden usarlo o no.
Términos clave
| Término | Significado |
|---|---|
| Lector de pantalla | Software que lee la pantalla en voz alta o a una línea braille, como VoiceOver, NVDA o JAWS. |
| Texto alternativo (alt) | Una descripción textual de una imagen, que leen los lectores de pantalla. Las imágenes decorativas llevan un alt vacío para que se omitan. |
| Relación de contraste | Lo distintos que son el color del texto y el del fondo, de 1:1 a 21:1. |
| Navegación por teclado | Usar un sitio con las teclas Tab, Intro, Espacio y las flechas en lugar del ratón. |
| Indicador de foco | El contorno visible que muestra en qué elemento está el teclado. |
| HTML semántico | Usar el elemento adecuado para cada función (<button>, <nav>, <h2>) para que los navegadores y las tecnologías de asistencia entiendan la página. |
| ARIA | Atributos adicionales que describen controles personalizados a las tecnologías de asistencia. Conviene usarlos con moderación; los elementos HTML nativos van primero. |
| Tecnología de asistencia | Herramientas que usan las personas para acceder a los ordenadores, desde lectores de pantalla hasta dispositivos de conmutación y control por voz. |
Falsas creencias habituales
- «La accesibilidad solo importa a las personas ciegas». Abarca discapacidades visuales, motoras, auditivas, del habla y cognitivas, además de situaciones temporales, como tener un brazo roto.
- «Los sitios accesibles se ven sosos». La accesibilidad limita unas pocas cosas (contraste, estilos de foco, tamaño del texto), pero los sitios accesibles y bien diseñados son lo normal, no la excepción.
- «Un comprobador automático da 100, así que hemos terminado». Las herramientas automáticas detectan solo algunos problemas. Si el texto alternativo tiene sentido de verdad, o si un flujo se entiende con un lector de pantalla, lo tiene que comprobar una persona.
- «Un widget de superposición nos hará cumplir la normativa». Las barras de herramientas añadidas encima no pueden corregir etiquetas que faltan ni un acceso por teclado roto en tu código. Arregla el origen.
- «No tenemos usuarios con discapacidad». Puede que simplemente no lo sepas. Muchas discapacidades no son visibles, y quien se topa con una barrera normalmente se va.
Qué pedir a tu creador con IA
- «Construye esto para que cumpla WCAG 2.2 en el nivel AA».
- «Usa HTML semántico: botones y enlaces reales, encabezados en orden y una etiqueta para cada campo de formulario».
- «Asegúrate de que cada elemento interactivo funcione solo con el teclado y tenga un estilo de foco visible».
- «Revisa el contraste de todos los colores de texto e iconos: 4,5:1 para texto normal, 3:1 para texto grande e iconos».
- «Añade texto alternativo significativo a las imágenes informativas y texto alternativo vacío a las decorativas».
- «Muestra los errores de formulario como texto, vinculado al campo, no solo con color».
- «Respeta la preferencia de movimiento reducido del usuario para las animaciones».
- «Ejecuta una comprobación automática de accesibilidad y enumera lo que no puede comprobar, para que yo lo revise a mano».
Después, pruébalo tú: aparta el ratón e intenta completar tu flujo principal usando solo Tab, Mayús+Tab, Intro y Espacio. Prueba el lector de pantalla integrado de tu teléfono en la página principal. Amplía el navegador al 200 % y mira si algo se rompe.
Accesibilidad en Mythex
Mythex no incluye un comprobador de accesibilidad específico, así que trata la accesibilidad como parte de tus prompts y de tus pruebas. Pide WCAG 2.2 AA desde el primer prompt, revisa el resultado en la vista previa con el teclado y usa /test para que el agente recorra tus flujos principales antes de publicar; consulta Pruebas de la app. La receta de SEO también pide encabezados semánticos y texto alternativo significativo, que sirven a ambos objetivos.
Para una lista práctica, consulta cómo hacer accesible tu sitio web. Para el diseño, lee cómo diseñar una app con buen aspecto con IA, y antes del lanzamiento, cómo probar tu app antes de lanzarla. La descripción general de WCAG del W3C es la fuente oficial.
Preguntas
¿Qué es la accesibilidad web en términos sencillos?
La accesibilidad web consiste en diseñar y construir sitios y apps para que las personas con discapacidad puedan percibirlos, entenderlos, navegarlos y usarlos. Incluye a personas ciegas que usan lectores de pantalla, a quienes no pueden usar el ratón, a personas con baja visión o daltonismo, a usuarios sordos y a personas con discapacidad cognitiva.
¿Qué es WCAG?
WCAG (Web Content Accessibility Guidelines, Pautas de Accesibilidad para el Contenido Web) es la norma internacional de accesibilidad web, publicada por el W3C. La versión actual es WCAG 2.2, publicada por primera vez en octubre de 2023. Sus criterios de éxito se clasifican en los niveles A, AA y AAA, y el nivel AA es el objetivo al que se refieren la mayoría de organizaciones y leyes.
¿Qué contraste de color exige WCAG?
En el nivel AA, el texto normal necesita una relación de contraste de al menos 4,5:1 frente a su fondo, y el texto grande (aproximadamente 18 puntos, o 14 puntos en negrita) necesita al menos 3:1. Los iconos y las partes visibles de los controles necesitan al menos 3:1 frente a lo que tienen al lado.
¿La accesibilidad web es un requisito legal?
En muchos lugares y para muchas organizaciones, sí. Las leyes varían según el país y el sector; por ejemplo, la Ley Europea de Accesibilidad cubre muchos productos y servicios digitales de consumo en la UE. Revisa las normas que te afectan o consulta a un asesor jurídico.
¿Un widget o superposición de accesibilidad puede hacer que mi sitio cumpla la normativa?
No por sí solo. Las superposiciones añaden una barra de herramientas encima de tu sitio, pero no pueden corregir de forma fiable problemas de fondo como etiquetas que faltan, una navegación con teclado inutilizable o una estructura poco clara. El enfoque fiable es arreglar el código y el contenido del sitio.