¿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: tanto si son ciegas y usan un lector de pantalla, como si no pueden usar el ratón, tienen baja visión o daltonismo, son sordas o tienen discapacidades cognitivas 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 correctas 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 se abrevia a menudo como a11y (la «a», once letras y la «y», igual que en inglés).
Por qué la accesibilidad importa cuando creas con IA
Los creadores con IA son buenos produciendo apps que se ven bien. 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 preguntarlo:
- Es fácil de pasar por alto. Un desplegable con estilo propio puede verse perfecto y ser imposible de usar sin ratón. No lo notarás si no lo pruebas.
- Es más barato hacerlo bien desde el principio. Pedir componentes accesibles desde el primer prompt cuesta casi nada. Adaptar una app terminada supone tocar cada pantalla.
- Beneficia a todos. Los subtítulos ayudan a quienes están en lugares ruidosos, un buen contraste ayuda a quienes usan el móvil a plena luz del 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 obligatoria. 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 a mucha gente. Una rampa sirve a las personas en silla de ruedas, y también a padres con cochecitos, repartidores con carros y viajeros con maletas. Las puertas automáticas, los carteles claros, 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 con 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 compatible hacia atrás: 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 versión muy distinta, WCAG 3, está en desarrollo como borrador temprano, no como estándar terminado.
WCAG se organiza en cuatro principios, que suelen recordarse con el acrónimo POUR (en inglés):
| Principio | Significado | Ejemplos |
|---|---|---|
| Perceptible | Las personas pueden captar el contenido con los sentidos que usan | Texto alternativo para las imágenes, subtítulos en los vídeos, contraste suficiente |
| Operable | Las personas pueden usar los controles y navegar | Acceso por teclado, sin límites de tiempo que no puedan ampliarse, 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 correctos, nombres y roles adecuados para los controles |
Cada pauta tiene criterios de éxito comprobables en tres niveles:
- Nivel A: el mínimo. Fallar en estos bloquea por completo a algunas personas.
- Nivel AA: el objetivo estándar, y el nivel al que apuntan la mayoría de las leyes y políticas.
- Nivel AAA: el nivel más alto. Conviene aspirar a él en algunas partes, pero el W3C no recomienda exigirlo para 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 en los que se pulsa deberían medir al menos 24 × 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» (Parsing) por obsoleto.
Un ejemplo práctico: un formulario de registro
Este es un formulario de registro que podría producir una IA, y lo que encuentra una comprobación de accesibilidad:
| Problema | A quién afecta | Solución |
|---|---|---|
| Los campos usan texto de marcador («Correo») en lugar de etiquetas | Usuarios de lectores 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 | Un 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 lectores 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 lectores de pantalla no pueden activarlo | Usar un elemento <button> real |
| No hay contorno visible al pasar por los campos con Tab | Los usuarios de teclado pierden la noción de dónde están | Un estilo de foco claro |
| La imagen del logotipo no tiene texto alternativo | Los usuarios de lectores 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 la envía a una pantalla 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 texto alternativo vacío para que se omitan. |
| Relación de contraste | Lo distintos que son los colores del texto y 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 sobre qué elemento está el teclado. |
| HTML semántico | Usar el elemento adecuado para cada cosa (<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; primero van los elementos HTML nativos. |
| Tecnología de asistencia | Herramientas que usan las personas para acceder a los ordenadores, desde lectores de pantalla hasta dispositivos de conmutación o control por voz. |
Malentendidos comunes
- «La accesibilidad solo importa a las personas ciegas.» Abarca discapacidades visuales, motoras, auditivas, del habla y cognitivas, además de situaciones temporales como un brazo roto.
- «Los sitios accesibles se ven sosos.» La accesibilidad limita algunas cosas (contraste, estilos de foco, tamaño del texto), pero los sitios accesibles y bonitos son la norma, no la excepción.
- «Un comprobador automático dice 100, así que hemos terminado.» Las herramientas automáticas detectan solo algunos problemas. Si un texto alternativo es realmente significativo, o si un flujo tiene sentido con un lector de pantalla, lo tiene que comprobar una persona.
- «Un widget de superposición nos hará cumplir.» Las barras 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.» Quizá simplemente no lo sepas. Muchas discapacidades no son visibles, y las personas que encuentran una barrera normalmente se van.
Qué pedir a tu creador con IA
- «Construye esto para cumplir WCAG 2.2 en el nivel AA.»
- «Usa HTML semántico: botones y enlaces reales, encabezados en orden y etiquetas para cada campo del formulario.»
- «Asegúrate de que cada elemento interactivo funcione solo con el teclado y tenga un estilo de foco visible.»
- «Comprueba el contraste de todos los colores de texto e iconos: 4,5:1 para el texto normal y 3:1 para el texto grande y los 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, vinculados al campo, y no solo con color.»
- «Respeta la preferencia de movimiento reducido del usuario en las animaciones.»
- «Ejecuta una comprobación automática de accesibilidad y enumera lo que no puede probar, para que yo lo revise a mano.»
Después, pruébalo tú mismo: 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 móvil 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 tu sitio web accesible. Para el diseño, lee cómo diseñar una app con buen aspecto con IA, y antes de publicar, cómo probar tu app antes del lanzamiento. La visión general de WCAG del W3C es la fuente autorizada.
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 percibir, entender, navegar 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 discapacidades cognitivas.
¿Qué es WCAG?
WCAG (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 las organizaciones y las 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 (unos 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, 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 legal.
¿Un widget o superposición de accesibilidad puede hacer que mi sitio cumpla?
No por sí solo. Las superposiciones añaden una barra de herramientas sobre 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.