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

Para hacer accesible una web, constrúyela de modo que la gente pueda usarla 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 un contraste alto del texto y haz visible el foco. El estándar al que aspirar 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 va de personas: alguien ciego que usa un lector de pantalla, alguien con temblor que navega con el teclado, alguien con baja visión que amplía al 200 %, alguien que lee con sol intenso, alguien con una muñeca rota temporalmente. Una buena accesibilidad tiende a mejorar la web para todos: una estructura más clara, textos legibles, 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 lo busca
A	El mínimo; sin él, algunas personas no pueden usar la web en absoluto	Todos
AA	El objetivo habitual; cubre contraste, foco, redimensionado y gestión de errores	La mayoría de organizaciones y muchas leyes
AAA	El más estricto; no es alcanzable para todo el contenido	Servicios y públicos específicos

Las leyes de varios 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 te afectan depende de dónde operes y de lo que vendas; consulta a un asesor si no estás seguro. Esta guía cubre el trabajo práctico.

Opciones: cómo llegar allí

Enfoque	Ideal para	Contrapartida
Construirla desde el principio	Webs y apps nuevas	Menor esfuerzo en conjunto; hay que plantearlo desde el inicio
Auditar y corregir	Webs existentes	Encuentra problemas reales; requiere una revisión concentrada por página
Auditoría profesional	Sectores regulados, webs grandes, organismos públicos	Exhaustiva y documentada; tiene un coste
Widget superpuesto	No recomendado	No puede corregir el código de fondo

Para la mayoría de webs pequeñas, las dos primeras opciones bastan: pide a la IA que construya de forma accesible desde el principio y audita antes del lanzamiento.

Las correcciones que más importan

Usa los elementos HTML adecuados

La mayor parte de la accesibilidad viene 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 <h1> por página, después <h2> y <h3> en orden: los usuarios de lectores de pantalla saltan entre encabezados
Regiones: <header>, <nav>, <main>, <footer>
Un <label> conectado a cada campo del formulario
El idioma de la página en <html lang="es">

Usa los 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 con teclado y foco visible

Todo lo que puedes hacer con el ratón debe funcionar solo con el teclado (WCAG 2.1.1). Recorre la página con el tabulador: 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 completamente 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 pueden cerrar con Escape, y outline: none en el CSS sin nada que lo sustituya.

Alternativas textuales

Cada imagen significativa necesita un texto alternativo que diga lo que muestra en su contexto («Chef sirviendo el menú de degustación», no «imagen1.jpg»). Las imágenes decorativas llevan un 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 un ratio 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 un 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.

Áreas de pulsación, formularios y errores

Tamaño de los objetivos: WCAG 2.2 AA pide objetivos de puntero de al menos 24 por 24 píxeles CSS, o un espaciado suficiente alrededor de los más pequeños (2.5.8). Más grande es más amable en los móviles.
Formularios: etiquetas visibles (no solo marcadores 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 la gente a resolver un acertijo ni a copiar un código sin una alternativa; permite los gestores de contraseñas y pegar texto (3.3.8 Autenticación accesible).

Instrucciones que funcionan

Construye esta web para cumplir WCAG 2.2 nivel AA: regiones semánticas HTML, un h1 por página con encabezados en orden, elementos button y a reales, etiquetas en cada campo del formulario, estilos de foco visibles, contraste de texto de al menos 4,5:1, texto alternativo en las imágenes significativas y alt="" en las decorativas, y el atributo html lang definido.

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 de los botones de icono para lectores de pantalla. Enumera cada problema con el criterio WCAG correspondiente y 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 al menú cuando se abra, 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 DevTools 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 el tabulador y completa cada tarea clave: registrarse, buscar, pagar. Anota todo lo que no puedas alcanzar, en lo que no veas el foco o de lo que no puedas salir.
Amplía al 200 % y estrecha la ventana al ancho de un móvil. Nada debe quedar cortado ni necesitar desplazamiento lateral.
Prueba un lector de pantalla durante diez minutos: VoiceOver en Mac y iPhone, TalkBack en Android o NVDA en Windows (gratuito). Escucha los encabezados, los enlaces y los campos del formulario. Un «Botón» sin nombre o un «enlace, haz clic aquí» indican trabajo pendiente.
Comprueba el contraste del texto, los botones y los campos con un comprobador 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 superpuesto en lugar de corregir el código.
Eliminar los contornos de foco porque quedan feos, sin ningún sustituto.
Usar el texto del marcador de posición como única etiqueta. Desaparece en cuanto alguien empieza a escribir y suele tener contraste bajo.
Enlaces de «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 con teclado. Añade una revisión con teclado a tus pruebas antes del lanzamiento.

Lista de comprobación de accesibilidad

Comprobación automática (Lighthouse o axe) sin errores 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, regiones, botones y enlaces semánticos; lang definido
Texto alternativo significativo; imágenes decorativas con alt=""; subtítulos en los vídeos
Contraste del 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 del 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 primera instrucción y en las siguientes. Puedes usar el marco de tamaño móvil de la vista previa para revisar las 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. Pídele al agente que audite una página, corrija lo que encuentre y luego prueba tú las correcciones: una revisión automática es un punto de partida, no una aprobación final.

Preguntas

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

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

¿Un widget de accesibilidad superpuesto puede hacer que mi web cumpla la normativa?

No te fíes de uno. Los widgets añaden una barra de herramientas encima de la página, pero no pueden corregir etiquetas que faltan, un acceso con teclado roto ni una estructura deficiente en el código de fondo. Arreglar la propia web es lo que la hace utilizable.

¿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é ratio 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 los componentes de la interfaz, como los bordes de los campos y los iconos que transmiten significado.