Convierte la accesibilidad en una capacidad operativa (no en un “extra”): guía para compradores
La accesibilidad no es una capa de “nice-to-have” que se añade al final. En sitios web y apps modernas es una capacidad operativa: algo que se define, se prueba y se mantiene-versión tras versión.
Cuando la accesibilidad falla, rara vez es por falta de intención. El problema típico es la deriva: se lanza con una accesibilidad razonable y, con el tiempo, pequeños cambios de diseño, nuevos componentes y actualizaciones de contenido rompen silenciosamente la navegación por teclado, las etiquetas, el contraste o los flujos con lector de pantalla.
Esta guía está pensada para compradores y product owners que quieren una manera clara de pedir, verificar y sostener la accesibilidad-sin necesidad de dominar cada detalle técnico.
1) Define criterios de aceptación medibles (para que “terminado” sea inequívoco)
Empieza por fijar un estándar objetivo. En muchas organizaciones esto significa WCAG 2.2 AA (o el nivel que requiera tu sector o normativa). Después tradúcelo a checks concretos que el equipo pueda validar en QA.
Ejemplos de criterios de aceptación fáciles de comprobar:
- Teclado: Todos los elementos interactivos son accesibles con teclado, el foco es siempre visible y no hay “trampas” de teclado.
- Formularios: Los campos tienen etiquetas programáticas, los obligatorios se entienden y los errores se anuncian de forma compatible con tecnologías de asistencia.
- Contraste: Texto y controles esenciales cumplen ratios mínimos, incluyendo estados hover/focus/disabled.
- Imágenes: Las imágenes significativas tienen alt útil; las decorativas se ignoran por lectores de pantalla.
- UI dinámica: Modales, toasts y actualizaciones en vivo anuncian los cambios correctamente (sin desorientar).
Consejo: pide una checklist de una página por tipo de plantilla (marketing, producto, checkout, dashboards) para poder aprobar de forma consistente.
2) Pide evidencia, no promesas
Las promesas suenan bien, pero necesitas pruebas. Exige un paquete de evidencia como parte de la entrega:
- Informe de auditoría con hallazgos, severidad y remediación aplicada.
- Matriz de pruebas de tecnologías de asistencia: qué browser + lector de pantalla se probó (por ejemplo, VoiceOver/Safari en macOS y NVDA/Chrome en Windows).
- Validación de recorridos críticos: notas o vídeos cortos mostrando que los flujos clave se completan (registro, compra, reserva, tareas principales).
En apps móviles, pregunta también cómo se validó en iOS y Android (VoiceOver y TalkBack), especialmente si hay componentes personalizados.
3) Integra checks automáticos en CI (para evitar regresiones)
La automatización no captura todo (especialmente matices de usabilidad), pero es excelente para evitar que errores comunes lleguen a producción.
Pide que la accesibilidad forme parte del pipeline de build:
- Linting para problemas básicos de semántica y ARIA.
- Tests automatizados de UI (a menudo basados en axe) en páginas críticas y estados comunes.
- Reglas de bloqueo que fallen el build si se introducen issues “críticos”.
Así, la accesibilidad deja de depender de auditorías puntuales y pasa a ser una práctica continua.
4) Haz que los entregables de accesibilidad figuren en contrato y SOW
Si no está por escrito, es difícil exigirlo. Tu statement of work debería incluir entregables de accesibilidad como outputs principales, por ejemplo:
- Criterios de aceptación por plantilla o feature.
- Remediación incluida para issues descubiertos en QA/UAT (con proceso y tiempos claros).
- Documentación para diseño y desarrollo: reglas de componentes, guía de contenido (alt text, estructura de headings) y tokens de diseño para contraste.
- Tiempo para re-auditorías post-lanzamiento (por ejemplo, a los 60–90 días, o trimestral si el producto evoluciona rápido).
Un detalle contractual útil: define cómo se triagean los issues (blocker/major/minor) y qué se considera “aceptable” antes del go-live.
5) Añade una gobernanza ligera para que no se degrade tras el lanzamiento
No necesitas burocracia; necesitas ownership y una rutina repetible:
- Nombra un responsable de accesibilidad del lado de producto y otro del lado técnico.
- Incluye accesibilidad en la definition of done (revisión de diseño, QA y checks de release).
- Haz una revisión trimestral de los flujos más importantes y de los nuevos componentes introducidos.
La buena accesibilidad rara vez es un único “proyecto”. Es el resultado de decisiones consistentes y checks repetibles.
En Jensen Technologies llevamos muchos años creando y manteniendo sitios web y apps móviles, y hemos visto la diferencia entre “intentaremos que sea accesible” y “la accesibilidad es parte de cómo entregamos.” El segundo enfoque reduce riesgos, mejora la experiencia para todos y a menudo incrementa conversión y retención.
Si quieres hablar sobre requisitos de accesibilidad para un nuevo proyecto, revisar el SOW de un proveedor o implantar pruebas y gobernanza práctica en un producto existente, ponte en contacto. Estaremos encantados de ayudarte a convertir la accesibilidad en una capacidad fiable en tu negocio.