Por dónde empezar con la accesibilidad cuando parece demasiado

Lo primero que debes entender: no tienes que arreglarlo todo de golpe

Cuando las organizaciones se encuentran por primera vez con las WCAG 2.2, la respuesta suele ser una mezcla de preocupación genuina y agobio. Hay 78 criterios de éxito repartidos en tres niveles de conformidad. La documentación de técnicas de apoyo es enorme. Los escaneos automatizados producen listas de cientos de problemas. Da la sensación de que tendrías que pararlo todo y dedicar meses de tiempo de desarrollo antes de siquiera poder pensar en llamar accesible a tu sitio.

Esta sensación es comprensible, pero engañosa. La mejora de la accesibilidad no es un estado binario —accesible o no accesible—. Es un espectro, y un progreso significativo es posible desde donde estés ahora mismo, incluso si donde estás es “no lo habíamos pensado antes”.

El objetivo de esta guía es ayudarte a empezar.

Por qué sentirse abrumado es normal

La accesibilidad web parece enorme porque genuinamente lo es. Las WCAG abarcan la presentación visual (contraste, tamaño del texto, espaciado), el contenido auditivo (subtítulos, transcripciones), la interacción (navegación por teclado, tiempo, movimiento), la semántica (estructura, etiquetas, roles) y las consideraciones cognitivas (lenguaje, coherencia, recuperación de errores). Se aplica en escritorio, móvil y tecnología de asistencia. Afecta al diseño, al contenido, al desarrollo y a las pruebas.

Pero esto es lo que cambia el panorama: la mayoría de los fallos de accesibilidad se agrupan en torno a un pequeño número de patrones. Año tras año, el informe WebAIM Million (que analiza el millón de sitios web más visitados) descubre que los mismos seis problemas representan la inmensa mayoría de los fallos WCAG detectables de forma automática:

Contraste de color bajo
Falta de texto alternativo en las imágenes
Falta de etiquetas en los campos de formulario
Enlaces vacíos (enlaces sin texto)
Falta del idioma del documento
Botones vacíos (botones sin texto)

Estos seis patrones por sí solos están presentes en más del 95% de las páginas de inicio analizadas. Corregirlos en tu sitio no te hace plenamente accesible, pero elimina barreras que afectan al mayor número de usuarios con discapacidad. Es un punto de partida significativo.

Paso 1: Comprende tu situación actual

Antes de poder priorizar las correcciones, necesitas saber dónde te encuentras. Un escaneo automatizado gratuito te da esto en minutos.

Las herramientas automatizadas no son una solución de accesibilidad completa: solo detectan de forma fiable entre el 30 y el 40% de los fallos WCAG, porque la mayoría de las barreras requieren el juicio humano para detectarse. Pero son excelentes para encontrar los fallos comunes y automatizables enumerados arriba: contraste, falta de texto alternativo, campos de entrada sin etiquetar y problemas estructurales similares.

Realiza un escaneo gratuito de tu sitio. Fíjate en lo que aparece. Los problemas señalados son reales —no serán falsos positivos para los patrones comunes— y son una lista de partida concreta.

Paso 2: Prioriza por impacto, no por exhaustividad

Una vez que tengas una lista, la tentación es abordar cada elemento por orden. Resístete. En su lugar, prioriza según la combinación de impacto y frecuencia:

Mayor impacto (arreglar primero):

Cualquier barrera en tu proceso de pago, registro o flujo de conversión principal: si los usuarios no pueden completar la transacción, el fallo de accesibilidad te está costando negocio
Barreras de inicio de sesión y autenticación: los usuarios que no pueden entrar no pueden usar nada
Navegación: si los usuarios no pueden encontrar las páginas, la accesibilidad a nivel de página no importa

Alto impacto (arreglar en segundo lugar):

Páginas de contenido principal: páginas de producto, páginas informativas, el contenido que los usuarios visitan específicamente para obtener
Campos de formulario y sus etiquetas y mensajes de error: los formularios son donde ocurre la interacción
Fallos de contraste: afectan a una población muy amplia y suelen ser correcciones sencillas

Importante pero de menor urgencia (arreglar más adelante):

Contenido de archivo y páginas más antiguas con poco tráfico
Interacciones de casos límite y criterios WCAG que afectan a poblaciones más pequeñas
Requisitos de Nivel AAA (que van más allá del estándar legal)

No necesitas alcanzar puntuaciones perfectas antes de que tus páginas de mayor tráfico y mayor conversión sean accesibles. Haz que esas funcionen bien primero.

Paso 3: Añade pruebas manuales para lo que la automatización pasa por alto

Una vez que tengas bajo control tus problemas automatizados, la siguiente capa son las pruebas manuales. Aquí es donde encontrarás:

Fallos de navegación por teclado: ¿pueden los usuarios tabular por todo tu sitio sin ratón?
Problemas de gestión del foco: después de que se abra una ventana modal, ¿se mueve el foco hacia ella? Después de que se cierre, ¿regresa?
Comportamiento del lector de pantalla: ¿anuncia tu menú desplegable personalizado su estado? ¿Comunica tu carrusel qué diapositiva está activa?
Orden de lectura lógico: si quitas el CSS, ¿sigue teniendo sentido la página?

La forma más rápida de empezar con las pruebas manuales es:

Desconecta el ratón e intenta completar el recorrido de usuario principal de tu sitio usando solo el teclado (Tab, Mayús+Tab, Intro, Espacio, Escape, teclas de flecha). Anota todo lo que falle.
Descarga un lector de pantalla gratuito (NVDA para Windows es gratuito; VoiceOver está integrado en Mac e iOS). Navega por tus páginas más importantes. Escucha lo que se anuncia. ¿Es coherente?
Usa las herramientas de accesibilidad del navegador: tanto Chrome como Firefox tienen inspectores de accesibilidad que muestran el árbol de accesibilidad, los roles ARIA y los nombres accesibles calculados de cada elemento.

Estas pruebas llevan tiempo aprenderlas, pero no cuestan nada, y encontrarán problemas que ninguna herramienta automatizada encontrará.

Paso 4: Intégrala en tu flujo de trabajo

La forma más cara de abordar la accesibilidad es tratarla como un ejercicio de subsanación: arreglar el sitio, cantar victoria y luego ver cómo se acumulan nuevas barreras con cada nueva versión de una función.

Una accesibilidad sostenible significa cambiar cómo trabajas:

Revisión de diseño: ¿cumple el diseño los requisitos de contraste? ¿Son visibles los estados interactivos?
Desarrollo: ¿se usan elementos HTML nativos siempre que es posible? ¿Están etiquetados los campos de formulario? ¿Tienen los componentes personalizados el ARIA correcto?
Contenido: ¿tiene cada imagen un texto alternativo apropiado? ¿Son descriptivos los enlaces?
Pruebas: ¿bloquea la CI las regresiones de accesibilidad? ¿Existe un paso de prueba manual antes de las versiones importantes?

Nuestra guía sobre la accesibilidad en el ciclo de vida del desarrollo de software profundiza en cómo se ve esto en la práctica. Nuestro servicio de integración CI/CD hace que la capa automatizada forme parte de cada compilación.

Establecer expectativas realistas

Para un sitio web que nunca ha sido revisado en cuanto a accesibilidad, alcanzar la conformidad WCAG 2.1 Nivel AA en cada página suele ser un proyecto de varios meses, más largo en sitios grandes y complejos con una cantidad significativa de código heredado.

Eso no significa que no puedas lograr un progreso significativo en las próximas dos semanas. Corregir los seis problemas más comunes que enumeré arriba hace que tu sitio sea materialmente más accesible para una población significativa, aunque no te haga legalmente conforme.

El enfoque que me resulta más útil: aspira a la mejora continua en lugar de a la conformidad como destino. En cada ciclo de sprint, resuelve un conjunto de problemas identificados. Ejecuta comprobaciones automatizadas en las nuevas funciones antes de que se publiquen. Programa pruebas manuales trimestralmente. Crea una declaración de accesibilidad que refleje honestamente tu estado actual y tu hoja de ruta.

Las organizaciones que lo abordan de esta manera tienden a progresar globalmente más rápido que las que esperan hasta poder dedicar recursos a un proyecto de subsanación completo.

Por dónde empezar hoy

Si aún no has hecho nada: realiza un escaneo gratuito. Tendrás una lista real de problemas reales en dos minutos, priorizada por gravedad. Ese es tu punto de partida.

Si has hecho escaneos pero no has pasado a las pruebas manuales: prueba hoy el test de solo teclado en tu proceso de pago. Si encuentras barreras, has encontrado tu siguiente prioridad.

Si estás haciendo pruebas manuales pero no las has integrado en tu flujo de trabajo: lee nuestra guía sobre la accesibilidad en el proceso de desarrollo e identifica un punto de tu flujo de trabajo actual donde podría añadirse una comprobación de accesibilidad.

El progreso vence a la perfección. Empieza por algún sitio.