Cómo hacer accesible tu web: una guía inicial de WCAG 2.2

Para hacer accesible una web, constrúyela de modo que se pueda usar con teclado, lector de pantalla, zoom o un dispositivo de conmutación, además del ratón: usa elementos HTML reales para botones, enlaces, encabezados y etiquetas de formulario; da a las imágenes un texto alternativo con sentido; mantén el texto con mucho contraste y haz visible el foco. El estándar al que apuntar es WCAG 2.2 Nivel AA. Los verificadores automáticos detectan una parte del problema; una prueba de diez minutos con teclado y lector de pantalla detecta gran parte del resto.

Qué significa «accesible» en la práctica

La accesibilidad trata de personas: alguien ciego que usa un lector de pantalla, alguien con temblores que navega con el teclado, alguien con baja visión que amplía al 200%, alguien que lee a plena luz del sol, alguien con una muñeca rota de forma temporal. Una buena accesibilidad suele mejorar la web para todos: estructura más clara, texto legible, formularios que explican sus errores.

La referencia es las Pautas de Accesibilidad para el Contenido Web (WCAG) del W3C. A septiembre de 2026, la versión vigente es WCAG 2.2 (publicada en octubre de 2023, actualizada en diciembre de 2024); WCAG 3 es un borrador temprano. WCAG se organiza en cuatro principios —el contenido debe ser perceptible, operable, comprensible y robusto— y tiene tres niveles de conformidad:

Nivel	Qué significa	Quién apunta a él
A	El mínimo; sin él, algunas personas no pueden usar el sitio en absoluto	Todos
AA	El objetivo habitual; cubre contraste, foco, redimensionado y gestión de errores	La mayoría de las organizaciones y muchas leyes
AAA	El más estricto; no es alcanzable para todo el contenido	Servicios y públicos específicos

Varias leyes en distintos lugares hacen referencia a WCAG —por ejemplo, la Ley Europea de Accesibilidad, que se aplica desde junio de 2025 a muchos servicios digitales de consumo en la UE—. Qué normas se aplican a ti depende de dónde operas y de qué vendes; consulta a un asesor si no estás seguro. Esta guía cubre el trabajo práctico.

Opciones: cómo llegar allí

Enfoque	Adecuado para	Contrapartida
Integrarla desde el principio	Webs y apps nuevas	Menos esfuerzo en total; hay que decirlo desde el inicio
Auditar y corregir	Webs existentes	Encuentra problemas reales; requiere una revisión concentrada por página
Auditoría profesional	Sectores regulados, sitios grandes, organismos públicos	Completa y documentada; tiene coste
Widget de superposición	No recomendado	No puede arreglar el código de fondo

Para la mayoría de sitios pequeños bastan los dos primeros: pide a la IA que construya con accesibilidad desde el principio y audita antes de lanzar.

Las correcciones que más importan

Usa los elementos HTML adecuados

La mayor parte de la accesibilidad llega gratis con un HTML correcto. Un <button> es enfocable, funciona con Intro y Espacio, y se anuncia como botón. Un <div> con un manejador de clic no hace nada de eso. El código generado por IA a veces usa div con estilo para todo; pide elementos semánticos:

<button> para acciones, <a href> para la navegación
Un solo <h1> por página, luego <h2> y <h3> en orden —los usuarios de lectores de pantalla saltan entre encabezados—
Puntos de referencia: <header>, <nav>, <main>, <footer>
<label> conectado a cada campo de formulario
El idioma de la página en <html lang="es">

Usa atributos ARIA solo cuando ningún elemento nativo encaje —por ejemplo, para un conjunto de pestañas o un combobox personalizado—. Un ARIA mal usado es peor que ninguno.

Acceso por teclado y foco visible

Todo lo que puedes hacer con el ratón debe funcionar solo con el teclado (WCAG 2.1.1). Pulsa Tab recorriendo la página: cada enlace, botón y campo debe ser alcanzable en un orden lógico, y siempre debes ver dónde está el foco (2.4.7 Foco visible). WCAG 2.2 añadió que el elemento enfocado no debe quedar totalmente oculto tras cabeceras fijas o banners de cookies (2.4.11, Nivel AA).

Fallos habituales: menús que solo se abren al pasar el ratón, modales que no atrapan el foco o no se cierran con Escape, y outline: none en el CSS sin nada que lo sustituya.

Alternativas textuales

Cada imagen con significado necesita un texto alternativo que diga lo que muestra en su contexto («Chef emplatando el menú degustación», no «imagen1.jpg»). Las imágenes decorativas llevan alt="" vacío para que los lectores de pantalla las omitan. Los botones solo con icono necesitan un nombre accesible («Cerrar», «Buscar»). Los vídeos necesitan subtítulos; el audio, una transcripción.

Color y contraste

WCAG 2.2 AA exige una relación de contraste de al menos 4,5:1 para el texto normal y 3:1 para el texto grande (1.4.3), y 3:1 para las partes de la interfaz como los bordes de los campos y los iconos significativos (1.4.11). El texto gris claro de los marcadores de posición y los botones pálidos son los fallos más habituales. Además, nunca uses solo el color para transmitir significado: un borde rojo en un campo no válido necesita también un mensaje de error.

Redimensionado y reflujo

El texto debe seguir siendo utilizable al ampliarlo al 200% (1.4.4), y el contenido debe funcionar con un ancho de 320 píxeles CSS sin desplazamiento lateral (1.4.10). Un diseño adaptable resuelve gran parte de esto.

Tamaños de objetivo, formularios y errores

Tamaño del objetivo: WCAG 2.2 AA exige objetivos de puntero de al menos 24 por 24 píxeles CSS, o suficiente espacio alrededor de los más pequeños (2.5.8). Más grande es más amable en el móvil.
Formularios: etiquetas visibles (no solo el marcador de posición), instrucciones claras y mensajes de error que digan qué está mal y cómo corregirlo, junto al campo.
Inicio de sesión: no obligues a resolver un acertijo ni a transcribir un código sin una alternativa; permite los gestores de contraseñas y pegar texto (3.3.8 Autenticación accesible).

Prompts que funcionan

Construye esta web para cumplir WCAG 2.2 Nivel AA: puntos de referencia semánticos, un solo h1 por página con encabezados en orden, elementos reales de botón y enlace, etiquetas en cada campo de formulario, estilos de foco visibles, contraste de texto de al menos 4,5:1, texto alternativo en las imágenes con significado y alt="" en las decorativas, y html lang configurado.

Audita las páginas /signup y /checkout en cuanto a accesibilidad. Comprueba el uso solo con teclado, el orden de foco, el foco visible, las etiquetas, los mensajes de error, el contraste y los nombres para lectores de pantalla de los botones de icono. Enumera cada problema con su criterio WCAG y luego corrígelos sin cambiar el diseño visual más de lo necesario.

El menú móvil no se puede usar con el teclado. Conviértelo en un botón con aria-expanded, mueve el foco dentro del menú al abrirlo, ciérralo con Escape y devuelve el foco al botón.

Paso a paso

Ejecuta una comprobación automática. La sección de Accesibilidad de Lighthouse en las herramientas de desarrollo de Chrome, o la extensión de navegador axe, en cada página principal. Corrige todo lo que informe.
Desconecta el ratón. Recorre cada página con Tab y completa cada tarea clave —registrarte, buscar, pagar—. Anota cualquier cosa a la que no llegues, en la que no veas el foco o de la que no puedas salir.
Amplía al 200% y reduce la ventana al ancho de un teléfono. Nada debe cortarse ni requerir desplazamiento lateral.
Prueba un lector de pantalla durante diez minutos: VoiceOver en Mac e iPhone, TalkBack en Android, o NVDA en Windows (gratuito). Escucha los encabezados, los enlaces y los campos de formulario. «Botón» sin nombre, o «enlace, haz clic aquí», significa trabajo pendiente.
Comprueba el contraste del texto, los botones y los campos con un verificador de contraste.
Corrige y vuelve a probar las mismas tareas.
Publica una declaración de accesibilidad que indique qué estándar persigues y cómo informar de problemas, y responde a esos informes.

Errores comunes

Confiar en un widget de superposición en lugar de arreglar el código.
Quitar los contornos de foco porque quedan feos, sin ponerlos de nuevo.
Usar el marcador de posición como única etiqueta. Desaparece en cuanto alguien empieza a escribir y suele tener poco contraste.
Enlaces «Haz clic aquí» y «Leer más». Fuera de contexto, los usuarios de lectores de pantalla oyen una lista de enlaces idénticos.
Texto alternativo cargado de palabras clave. El texto alternativo es para las personas; describe la imagen.
Probar una sola vez. Cada nueva función puede romper el acceso por teclado. Añade una revisión con teclado a tus pruebas previas al lanzamiento.

Lista de comprobación de accesibilidad

La comprobación automática (Lighthouse o axe) está limpia en las páginas principales
Cada tarea se puede completar solo con el teclado
El foco siempre es visible y nunca queda oculto tras elementos fijos
Encabezados, puntos de referencia, botones y enlaces semánticos; lang configurado
Texto alternativo con sentido; imágenes decorativas con alt=""; subtítulos en el vídeo
Contraste de texto ≥ 4,5:1 (texto grande ≥ 3:1); partes de la interfaz ≥ 3:1
Funciona con zoom al 200% y con un ancho de 320 px
Cada campo de formulario tiene una etiqueta visible y mensajes de error claros
Declaración de accesibilidad con una forma de informar de problemas

Para los conceptos detrás de esto, lee qué es la accesibilidad web. El diseño accesible y el buen diseño se solapan mucho; cómo diseñar una app atractiva con IA cubre el lado visual.

Accesibilidad en Mythex

Mythex construye con el estándar que le pidas, así que pon «WCAG 2.2 AA» en tu primer prompt y en las peticiones de seguimiento. Puedes usar el marco de tamaño de teléfono de la vista previa para revisar pantallas pequeñas (Vista previa y código), pero las pruebas de teclado, zoom y lector de pantalla funcionan mejor en la URL publicada o en una vista previa abierta en su propia pestaña. Pide al agente que audite una página, corrija lo que encuentre y luego prueba tú las correcciones: una pasada automática es un comienzo, no una aprobación final.

Preguntas

¿Cuál es el estándar de accesibilidad vigente para webs?

A septiembre de 2026, el estándar actual del W3C es WCAG 2.2, publicado por primera vez en octubre de 2023. La mayoría de las organizaciones y muchas leyes apuntan al Nivel AA. WCAG 3 sigue siendo un borrador temprano.

¿Puede un widget de superposición hacer mi web conforme?

No te fíes de uno. Las superposiciones añaden una barra de herramientas sobre la página, pero no pueden arreglar etiquetas que faltan, un acceso por teclado roto ni una estructura deficiente en el código de fondo. Lo que hace utilizable el sitio es arreglar el propio sitio.

¿Los verificadores automáticos encuentran todos los problemas?

No. Herramientas como Lighthouse y axe detectan cosas como texto alternativo ausente, contraste bajo y campos sin etiqueta, pero muchos problemas —un orden de foco confuso, textos de enlace sin significado, texto alternativo presente pero incorrecto— necesitan que una persona lo compruebe con el teclado y un lector de pantalla.

¿Qué relación de contraste exige WCAG?

WCAG 2.2 Nivel AA exige al menos 4,5:1 para el texto normal y 3:1 para el texto grande, y 3:1 para componentes de la interfaz como los bordes de los campos y los iconos que transmiten significado.