Un proceso de pruebas de accesibilidad que los equipos web pueden sostener

Un proceso repetible para probar la accesibilidad de un sitio web: qué automatizar, qué debe revisar una persona a mano, cómo muestrear páginas, quién da el visto bueno, cómo registrar y corregir incidencias, y un filtro de publicación que impide que salgan problemas nuevos.

La mayoría de los equipos web ha encargado al menos una auditoría de accesibilidad. Un consultor revisó 40 páginas, entregó un informe de 90 páginas y, seis meses después, la mitad de las correcciones estaban hechas y se habían publicado el doble de problemas nuevos. El fallo no fue la auditoría. Lo que faltaba era un proceso: una forma de probar que se repita cada vez que algo cambia, a cargo de personas que ya forman parte del equipo. Esta guía lo describe en el orden en que conviene introducirlo.

El principio: tres capas, cada una detecta lo que las otras no ven

La Iniciativa de Accesibilidad Web (WAI) del W3C lo dice con claridad: las herramientas de evaluación ayudan, pero ninguna herramienta por sí sola puede determinar si un sitio cumple los estándares de accesibilidad. Por eso un proceso sensato tiene tres capas.

Capa	Detecta	No detecta	Cuándo se ejecuta
Comprobaciones automáticas	Atributos alt ausentes, bajo contraste de color en texto simple, formularios sin etiquetas, enlaces vacíos, IDs duplicados, idioma de la página sin declarar	Si el texto alternativo tiene sentido, si el orden del foco es lógico, si un widget personalizado funciona con un lector de pantalla, si las instrucciones dependen del color o la forma	En cada cambio de página, idealmente de forma automática
Revisiones manuales del equipo	Trampas de teclado, foco invisible, encabezados confusos, textos de enlace poco claros, zoom y reajuste rotos, mensajes de error deficientes	Las fricciones reales para quienes usan tecnologías de apoyo a diario	Antes de cada lanzamiento y en plantillas nuevas
Pruebas con usuarios con discapacidad	Si la tarea se puede completar de verdad: pagar una factura, reservar una sala, solicitar un permiso	La cobertura completa del estándar	Una o dos veces al año en las tareas más importantes

Los equipos que dependen de una sola capa obtienen resultados previsibles. Los que solo automatizan aprueban el escáner y fallan a los usuarios reales. Los que solo revisan a mano no dan abasto con el volumen de cambios. Los que solo hacen pruebas con usuarios encuentran problemas grandes y pasan por alto cientos de pequeños.

Elija su objetivo y déjelo por escrito

Decida contra qué estándar va a probar y regístrelo en su política. Muchas organizaciones usan WCAG 2.1 nivel AA porque es el estándar de la norma del Departamento de Justicia para gobiernos estatales y locales bajo el Título II de la ADA. WCAG 2.2 es la Recomendación vigente del W3C; añade criterios (por ejemplo, sobre el foco no oculto y el tamaño del objetivo) y elimina el 4.1.1 Procesamiento por obsoleto. Probar contra 2.2 AA también cubre 2.1 AA salvo Procesamiento, así que muchos equipos prueban con 2.2 e informan según la versión que exija su obligación legal. Consulte Sección 508 vs Título II de la ADA vs WCAG para saber cuál aplica a quién.

Paso 1: Elija qué probar (muestreo)

No se puede revisar a mano cada página en cada lanzamiento. Use una muestra que represente el sitio, una idea tomada de la metodología de evaluación del W3C (WCAG-EM).

Cada plantilla. Inicio, página de aterrizaje, artículo, listado, resultados de búsqueda, formulario, página de error, evento, noticias, directorio de personal. Los errores de plantilla se repiten en todas las páginas que la usan, así que corregir uno corrige cientos.
Cada componente. Menús, acordeones, pestañas, carruseles, ventanas modales, selectores de fecha, mapas, reproductores de video, avisos de cookies, widgets de chat.
Las tareas principales. Las cinco a diez cosas que más gente viene a hacer. Para un ayuntamiento podrían ser pagar el recibo del agua, reportar un bache, encontrar órdenes del día de reuniones y solicitar un permiso.
Un puñado al azar. De cinco a diez páginas elegidas al azar, para detectar problemas de contenido que las plantillas no explican.

Anote la muestra en una tabla breve y manténgala bajo control de versiones. Amplíela cuando aparezca una plantilla o un componente nuevo.

Paso 2: La revisión manual que hace cada evaluador

Este es el núcleo del proceso. Lleva de 15 a 30 minutos por página cuando se tiene práctica, y no requiere software especial más allá de un navegador y el lector de pantalla gratuito del sistema operativo.

#	Revisión	Cómo	Así se ve un fallo
1	Solo teclado	Aparte el ratón. Recorra toda la página con Tab y use Enter, Espacio, las flechas y Escape	Algo no se puede alcanzar ni accionar; el foco se queda atascado; un menú no se puede cerrar
2	Foco visible	Mientras tabula, ¿siempre ve dónde está?	El foco desaparece o queda oculto tras una cabecera fija
3	Orden del foco	¿El foco avanza en un orden lógico?	Salta de la cabecera al pie y vuelve; se abre una ventana modal pero el foco se queda detrás
4	Zoom y reajuste	Amplíe al 200% y al 400%; estreche la ventana	Texto cortado, desplazamiento horizontal en el texto principal, elementos superpuestos
5	Encabezados	Revise el esquema de encabezados con una extensión del navegador o un lector de pantalla	Sin H1, niveles saltados por estética, encabezados que solo son texto en negrita
6	Imágenes	Lea el texto alternativo fuera de contexto	"image1.jpg", "foto" o la descripción de un adorno decorativo; gráficos informativos sin equivalente textual
7	Enlaces y botones	Liste todos los enlaces; ¿se entienden por sí solos?	Diez enlaces que dicen "Haga clic aquí" o "Más información"
8	Formularios	Envíelo vacío y luego con valores incorrectos	Errores mostrados solo en rojo, no anunciados o no vinculados al campo; etiquetas que desaparecen al escribir
9	Pasada con lector de pantalla	Active el lector de pantalla y complete la tarea principal de la página	Botones sin etiqueta, contenido anunciado dos veces, cambios dinámicos no anunciados
10	Movimiento y multimedia	Reproduzca los videos y observe las animaciones	Sin subtítulos, movimiento automático sin pausa, destellos
11	Dependencia del color	¿La página seguiría teniendo sentido en escala de grises?	Campos obligatorios o estados indicados solo con color
12	Documentos	Abra cada PDF o archivo de ofimática enlazado en la muestra	Imágenes escaneadas de texto, sin etiquetas, sin orden de lectura

Nuestra lista de verificación de accesibilidad web repasa criterio por criterio si quiere la versión larga. La tabla de arriba es la versión que la gente realmente aplicará cada semana.

Paso 3: Registre las incidencias para que se corrijan

Una buena incidencia es la que un desarrollador o editor puede corregir sin hacer preguntas. Use la misma plantilla para todas.

Campo	Ejemplo
Dónde	Plantilla: página de evento. URL: /events/summer-concert
Qué ocurre	El menú "Añadir al calendario" se abre con Enter pero no se cierra con Escape; el foco se queda dentro
A quién afecta	Usuarios de teclado y de lector de pantalla
Criterio	WCAG 2.1.2 Sin trampas para el foco del teclado
Gravedad	Bloqueante / Grave / Leve (definiciones abajo)
Cómo reproducirla	Tabule hasta "Añadir al calendario", pulse Enter, pulse Escape
Corrección sugerida	Cerrar el menú con Escape y devolver el foco al botón que lo abre
Responsable	Desarrollador front-end (plantilla) o editor de contenido (contenido)

Definir la gravedad acorta las discusiones:

Bloqueante: alguien no puede completar una tarea. Se corrige antes del lanzamiento; si ya está publicado, esta semana.
Grave: la tarea es posible pero mucho más difícil. Se corrige en el siguiente lanzamiento.
Leve: molesta, pero no impide. Se corrige la próxima vez que se toque la página.

Separe las incidencias por responsable. Los errores de plantillas y componentes van a desarrollo y se corrigen una sola vez. Los de contenido (texto alternativo, encabezados, texto de enlaces, documentos) van al departamento dueño de la página. Mezclarlos en una sola cola es la manera de que los problemas de contenido sigan sin corregirse durante un año.

Paso 4: Ponga un filtro antes de publicar

Probar después de publicar solo mide el daño. La corrección más barata es la que se hace antes de que una página salga en vivo. Tres filtros, del más ligero al más firme:

Autorrevisión del editor. Una lista de cinco puntos en la formación de los editores: encabezados en orden, texto alternativo con sentido, enlaces descriptivos, nada de PDF nuevos donde bastaría una página, subtítulos en los videos.
Revisión automática al guardar. Si su plataforma o su flujo de publicación lo permite, pase un escáner por las páginas modificadas y muestre los resultados al editor.
Revisión antes de publicar. Un revisor formado examina las páginas nuevas, los sitios nuevos y los cambios importantes antes de que se publiquen. Este es el filtro que detecta lo que las herramientas no pueden.

Para organizaciones que gestionan muchos sitios, el tercer filtro es donde las plataformas se diferencian. En We.Inc, una organización puede configurar cualquier sitio para que la publicación requiera una aprobación de un solo paso antes de salir en vivo, y la solicitud llega a una cola de aprobación. No prueba la accesibilidad por usted; le da a su revisor un momento fijo para hacerlo.

Configuración predeterminada de toda la marca titulada What your clients can do, con interruptores para cada permiso y una lista del equipo — Permisos predeterminados para todos los sitios de la organización, configurados una sola vez.

Una cola de aprobación con un sitio y los botones Approve and publish y Ask for changes — Un revisor puede aprobar o pedir cambios. La solicitud que se ve se preparó para la captura; la pantalla es la del producto real.

El editor visual con un encabezado seleccionado y sus controles de fuente, tamaño y color abiertos — Los editores cambian encabezados y estilos en un editor visual. Los niveles de encabezado y el contraste deben revisarse igualmente.

Un panel de código con el árbol de archivos y el código fuente de un componente Hero, con un botón Download — Los desarrolladores pueden leer y descargar el código fuente del sitio, algo útil cuando hace falta una corrección a nivel de plantilla.

Paso 5: Ritmo e informes

Con qué frecuencia	Qué	Quién
En cada cambio	Escaneo automático; autorrevisión del editor	Editores, flujo de publicación
En cada lanzamiento	Revisión manual de 12 puntos en plantillas y componentes modificados	Evaluador del equipo web
Mensual	Revisión manual de la muestra; recuento de incidencias abiertas por gravedad	Responsable de accesibilidad
Dos veces al año	Pruebas por tareas con usuarios con discapacidad en las tareas principales	Responsable de accesibilidad, participantes remunerados
Anual	Auditoría independiente contra el estándar elegido; revisión de la muestra; actualización de la declaración de accesibilidad	Auditor externo

Informe cada mes dos cifras a la dirección: bloqueantes abiertos y graves abiertos. No una puntuación. Las puntuaciones de las herramientas automáticas suben y bajan por motivos que nada tienen que ver con los usuarios, y se prestan a la manipulación.

Quién hace qué

Responsable de accesibilidad. Es dueño del proceso, la muestra y la cola de incidencias. En una organización pequeña no tiene que dedicarse a tiempo completo, pero debe estar designado por nombre.
Evaluadores. Cualquier desarrollador, diseñador o persona de QA formada en la revisión de 12 puntos. Forme al menos a dos para que las vacaciones no frenen los lanzamientos.
Editores. Formados en la autorrevisión. La mayoría de los problemas de contenido los crean editores bienintencionados a quienes nadie enseñó cómo funcionan los encabezados y el texto alternativo.
Participantes con discapacidad. Remunerados, reclutados a través de organizaciones locales de personas con discapacidad o de un panel de investigación, y a quienes se pide completar tareas, no "revisar el sitio web".
Compras. Todo producto de un nuevo proveedor pasa la misma revisión manual antes de la compra, no después. Nuestra lista de verificación de compras incluye preguntas para hacer.

Errores que deshacen el proceso

Comprar un overlay en lugar de corregir el código. Los scripts que prometen hacer accesible un sitio automáticamente no corrigen el marcado de fondo, y algunos crean problemas nuevos a los usuarios de lectores de pantalla.
Tratar la auditoría anual como si fuera el proceso. Es un control del proceso.
Probar solo en escritorio. Haga también las revisiones de teclado y lector de pantalla en un teléfono; muchos visitantes del sector público solo usan el móvil.
Aceptar un "conforme" de un proveedor sin pruebas. Pregunte cómo lo probaron, contra qué versión, y pida ver los resultados. Ninguna plataforma, incluida la nuestra, puede garantizar que el contenido que añada su equipo sea accesible.

Si gestiona muchos sitios y quiere un paso de revisión antes de cada uno, agende una demostración y le mostraremos la configuración de aprobaciones y permisos en una marca real.

Fuentes

Última revisión: 2026-10-25.

W3C WAI, Evaluating Web Accessibility Overview (las herramientas por sí solas no pueden determinar la conformidad; WCAG-EM).
W3C, Web Content Accessibility Guidelines (WCAG) 2.2 (4.1.1 Procesamiento, obsoleto y eliminado).
ADA.gov, Fact Sheet: Title II web and mobile app rule (WCAG 2.1 AA; fechas de cumplimiento modificadas).

Esta guía es información general, no asesoramiento legal.

Preguntas frecuentes

¿Pueden las herramientas automáticas probar la accesibilidad por sí solas?

No. El W3C afirma que ninguna herramienta por sí sola puede determinar si un sitio cumple los estándares de accesibilidad. Las comprobaciones automáticas detectan rápido una parte de los problemas; las revisiones manuales y las pruebas con usuarios con discapacidad detectan el resto.

¿Cuántas páginas debemos revisar a mano?

Revise una muestra representativa en lugar de cada página: todas las plantillas, todos los componentes, las cinco a diez tareas principales y algunas páginas al azar. Amplíe la muestra cuando aparezcan plantillas nuevas.

¿Debemos probar contra WCAG 2.1 o 2.2?

Pruebe contra la versión que nombre su obligación; el Título II de la ADA usa WCAG 2.1 AA. Muchos equipos prueban con WCAG 2.2 AA, que también cubre 2.1 AA salvo el criterio de Procesamiento eliminado.

¿Cómo se deben priorizar las incidencias de accesibilidad?

Use tres niveles de gravedad: los bloqueantes impiden una tarea y se corrigen antes del lanzamiento, los graves la dificultan mucho y se corrigen en el siguiente lanzamiento, y los leves se corrigen la próxima vez que se toque la página.

¿We.Inc hace accesibles los sitios automáticamente?

No. We.Inc puede exigir una aprobación de un solo paso antes de que un sitio salga en vivo, lo que da a su revisor un momento fijo para probar, pero su equipo debe seguir probando cada sitio.