Accesibilidad web: una guía práctica de WCAG

La mayoría de los equipos descubre la accesibilidad por las malas: un aviso legal, un contrato empresarial perdido o un usuario que sencillamente no puede completar la compra. Para entonces las correcciones son caras y el costo reputacional ya está pagado. En Innovation T tratamos la accesibilidad como una disciplina de ingeniería, no como una tarea de cumplimiento, y esta guía es el conocimiento práctico que llevamos a proyectos reales.

La buena noticia es que casi todo lo que hace accesible a un sitio también lo hace más rápido, más limpio y más fácil de mantener. El marcado semántico, un foco predecible y las etiquetas claras son simplemente buena ingeniería de frontend. Veamos qué pide realmente WCAG y cómo cumplirlo.

Qué es WCAG, en términos sencillos

WCAG son las siglas de Web Content Accessibility Guidelines, publicadas por el W3C. A fecha de 2026, la versión estable y ampliamente referenciada es WCAG 2.2, mientras que WCAG 3.0 sigue siendo un borrador de trabajo que señala hacia dónde van las cosas pero que todavía no es algo con lo que puedas cumplir. Cuando un contrato, una licitación pública o la European Accessibility Act exigen cumplimiento, casi siempre se refieren a WCAG 2.1 o 2.2 en el nivel AA.

Las pautas se organizan en torno a cuatro principios, recordados a menudo por las siglas en inglés POUR:

• Perceptible: los usuarios pueden percibir el contenido, por ejemplo mediante alternativas textuales, subtítulos y contraste suficiente.
• Operable: los usuarios pueden operar la interfaz, incluso solo con el teclado, sin trampas de tiempo.
• Comprensible: el contenido y el comportamiento son predecibles, con etiquetas claras y mensajes de error útiles.
• Robusto: el marcado funciona de forma fiable en navegadores y tecnologías de asistencia.

Cada principio se divide en criterios de conformidad calificados como A, AA o AAA. AA es el objetivo práctico para casi todo el mundo. El nivel AAA vale la pena alcanzarlo en criterios específicos, pero rara vez se exige en todo el sitio.

Los criterios que más importan en la práctica

No necesitas memorizar todo WCAG para marcar una diferencia real. Según nuestra experiencia, un puñado de problemas explica la gran mayoría de lo que realmente encuentran los análisis automáticos y los usuarios reales. Corrige estos primero.

Contraste de color

El texto necesita contraste suficiente respecto a su fondo: una relación de al menos 4,5 a 1 para el texto normal y de 3 a 1 para el texto grande. El contraste bajo es el fallo más común que encontramos en las auditorías, y a menudo resulta invisible para diseñadores con buena vista frente a un portátil luminoso. Integra las comprobaciones de contraste en tus design tokens para que una combinación no conforme nunca llegue a producción.

Cuidado con la compensación: las paletas de marca a veces se apoyan en texto gris claro para lograr un aspecto moderno. Puedes conservar la estética reservando el contraste bajo para elementos decorativos y no esenciales, y usando valores conformes para todo lo que un usuario deba leer.

Operabilidad con teclado

Cada elemento interactivo debe ser alcanzable y utilizable solo con el teclado. Pruébalo tú mismo: aparta el ratón y recorre un flujo clave con la tecla Tab. Buscas tres cosas.

1. Todo lo que puede recibir el foco es alcanzable en un orden lógico.
2. El indicador de foco siempre es visible, nunca se elimina con outline: none dejándolo sin reemplazo.
3. El foco nunca queda atrapado, salvo de forma intencional dentro de una ventana modal de la que puedas salir.

Los componentes personalizados son donde esto se rompe. Un div estilizado para parecer un botón es invisible para el teclado y para los lectores de pantalla. Usa un button real o, si debes usar un elemento genérico, añade role, tabindex y manejadores de teclas, lo que supone estrictamente más trabajo para un peor resultado.

Formularios y etiquetas

Los formularios son donde los fallos de accesibilidad cuestan dinero de verdad, porque bloquean las conversiones. Asocia cada campo con un <label> visible, describe los errores con texto en lugar de solo con color, y conecta los mensajes de error con su campo mediante aria-describedby. No desactives el botón de envío de una forma que oculte por qué está desactivado, ya que un usuario con lector de pantalla quizá nunca sepa qué falta.

Imágenes y multimedia

Cada imagen con significado necesita un atributo alt que transmita su propósito, no una descripción literal de píxeles. Las imágenes decorativas deben llevar un alt="" vacío para que los lectores de pantalla las omitan. El vídeo necesita subtítulos, y el contenido con mucho audio se beneficia de una transcripción. Todo esto también ayuda al SEO, tema que tratamos en nuestra guía sobre el SEO que genera ingresos.

El HTML semántico casi siempre supera a ARIA

La primera regla de ARIA es: no uses ARIA si un elemento nativo sirve. Un <button>, <nav>, <main>, <input> o <details> nativo trae gratis el comportamiento de teclado, la gestión del foco y la semántica para lectores de pantalla. ARIA solo añade una descripción del comportamiento, no añade el comportamiento en sí, así que un div role="button" todavía requiere que conectes Enter y Espacio a mano.

Recurre a ARIA cuando construyas de verdad algo que la plataforma no ofrece, como un combobox personalizado, un conjunto de pestañas o una región live que anuncie actualizaciones asíncronas. Incluso entonces, sigue los patrones establecidos en las WAI-ARIA Authoring Practices en lugar de inventar los tuyos. Un ARIA mal hecho es peor que ninguno, porque miente activamente a la tecnología de asistencia sobre lo que es un elemento.

Una heurística rápida que usamos en las revisiones: si un componente tiene más atributos role y aria-* que funcionalidad real, algo ha salido mal.

Pruebas: automáticas, manuales y humanas

Ningún método único lo detecta todo. Las herramientas automáticas encuentran de forma fiable, según nuestra experiencia, quizá entre un tercio y la mitad de los problemas, y son excelentes para las comprobaciones mecánicas. El resto necesita una persona. Este es el enfoque por capas que usamos.

• Automático en CI: ejecuta axe-core o Lighthouse contra las páginas clave en cada build para que las regresiones hagan fallar el pipeline y no al cliente. Es la misma mentalidad shift left que aplicamos a la seguridad, y encaja de forma natural con una sólida auditoría de seguridad para tu sitio web.
• Pasada de teclado: recorre manualmente cada flujo crítico con la tecla Tab. Es rápido, gratuito y detecta lo que los escáneres no pueden.
• Pasada de lector de pantalla: prueba con NVDA en Windows, VoiceOver en macOS e iOS, y TalkBack en Android. Cada herramienta expone errores distintos.
• Zoom y readaptación: amplía al 200 por ciento y al 400 por ciento, y comprueba que el diseño sigue funcionando en una ventana estrecha sin desplazamiento horizontal.
• Usuarios reales: cuando el presupuesto lo permite, probar con personas que dependen de tecnologías de asistencia saca a la luz problemas que ninguna lista predice.

Una lista de verificación de accesibilidad lista para publicar

Úsala como control previo a la publicación. Es deliberadamente corta para que los equipos la ejecuten de verdad.

1. Cada página tiene un solo <h1> y un orden de encabezados lógico, sin saltar niveles.
2. Todos los elementos interactivos son alcanzables y utilizables con el teclado, con un anillo de foco visible.
3. El contraste del texto cumple 4,5 a 1, y el texto grande cumple 3 a 1.
4. Cada campo tiene una etiqueta visible asociada, y los errores se describen con texto.
5. Las imágenes tienen texto alt apropiado, las imágenes decorativas usan alt="".
6. El vídeo tiene subtítulos y, cuando corresponde, una transcripción.
7. La página tiene un atributo lang correcto y un <title> descriptivo y único.
8. El contenido y el diseño sobreviven a un zoom del 200 por ciento sin pérdida de función.
9. El movimiento respeta prefers-reduced-motion para usuarios propensos al mareo por movimiento.
10. Un análisis automático pasa en CI sobre las plantillas principales.

Dónde encaja la accesibilidad en una arquitectura moderna

La accesibilidad es más fácil cuando vive en componentes compartidos en lugar de reaplicarse página por página. Un buen sistema de diseño codifica las relaciones de contraste en tokens, entrega un único botón y un único campo de entrada accesibles, y hace difícil tomar la decisión equivocada. Esta es una razón más por la que importan los límites de componentes y servicios que eliges, un tema que exploramos en del monolito a los microservicios.

Las páginas renderizadas en el servidor y mejoradas progresivamente tienden a ser más robustas que las aplicaciones pesadas del lado del cliente, porque el contenido existe en el marcado antes de que se ejecute JavaScript. Si tu framework hidrata tarde, asegúrate de que el estado previo a la hidratación siga siendo legible y de que el foco se gestione correctamente tras la navegación del lado del cliente, un fallo común y fácil de pasar por alto en las aplicaciones de página única.

Cómo puede ayudar Innovation T

La accesibilidad no es una limpieza puntual, es una propiedad que diseñas desde el principio y defiendes con el tiempo. Nuestros equipos la integran en el trabajo desde el primer wireframe: sistemas de diseño accesibles, frontends semánticos y de alto rendimiento, comprobaciones automáticas en tu pipeline, y auditorías completas WCAG 2.2 AA con un plan de corrección priorizado y en lenguaje claro, en lugar de una hoja de cálculo intimidante.

Si estás lanzando algo nuevo, nos aseguramos de que salga accesible. Si tienes un producto existente bajo presión legal o de compras, lo auditamos, corregimos primero los problemas de mayor impacto y establecemos salvaguardas para que no retrocedas. Explora nuestros servicios para ver cómo se unen el diseño UI/UX, el desarrollo web y la ingeniería de software, y ponte en contacto para hablar de tus objetivos concretos. Construir para todos no es una restricción para el buen trabajo, es el aspecto que tiene el buen trabajo.