Desarrollo

Accesibilidad en software: cómo llevar WCAG del backlog al CI/CD

La accesibilidad no es un ajuste que se aplica al final del proyecto. Es un requisito de producto que debe aparecer en el sistema de diseño, los criterios de aceptación, las pruebas y la documentación pública, y seguir funcionando después de cada entrega.

6 de noviembre de 202612 min de lecturaEquipo ProativaIA
Interfaces web y móvil accesibles conectadas con teclado, lector de pantalla, contraste, foco visible, subtítulos y objetivos táctiles adecuados

Un formulario puede superar todas las pruebas funcionales y seguir siendo imposible de utilizar sin ratón. Una aplicación puede tener buen contraste en una pantalla y perder su estructura cuando se amplía el texto. Si la corrección de última hora no se convierte en componente, prueba y regla de revisión, volverá a romperse.

El 5 de noviembre de 2026, GitHub anunció un espacio visible para ACCESSIBILITY.md, donde documentar objetivos, barreras conocidas, entornos compatibles y canales de notificación. La iniciativa refleja una realidad: la accesibilidad en software debe ser continua y verificable, no una declaración genérica.

Qué organiza WCAG 2.2

Las Pautas de Accesibilidad para el Contenido Web agrupan los criterios en cuatro principios: perceptible, operable, comprensible y robusto. Los niveles A, AA y AAA expresan conformidad. W3C recomienda la versión más reciente y proporciona orientación para experiencias móviles.

En Europa, la accesibilidad también tiene peso normativo. El European Accessibility Act cubre productos y servicios como teléfonos inteligentes, comercio electrónico, banca, transporte y libros electrónicos. La referencia técnica suele combinar WCAG con EN 301 549.

Empieza por el recorrido, no por la lista

Los criterios técnicos son imprescindibles, pero la meta es completar tareas. Mapea recorridos críticos: alta, compra, pago, cita, seguimiento, envío de documentos y soporte. Después, prueba diferentes formas de interacción.

Teclado y foco

El orden debe seguir el significado visual, el foco tiene que ser visible y ningún componente puede atraparlo. Los diálogos deben moverlo y devolverlo correctamente.

Lector de pantalla y semántica

Utiliza elementos nativos, etiquetas asociadas, encabezados jerárquicos y mensajes anunciados. ARIA complementa la semántica; no repara una estructura incorrecta.

Contraste, zoom y texto ampliado

El color no puede ser la única señal. La interfaz debe conservar contenido y funcionalidad al ampliar, sin solapamientos ni desplazamientos innecesarios.

Tacto, movimiento y multimedia

Los objetivos pequeños provocan errores y los gestos complejos requieren alternativa. Las animaciones deben respetar la reducción de movimiento. Los vídeos necesitan subtítulos y, cuando corresponda, audiodescripción.

Convierte requisitos en componentes

El sistema de diseño multiplica el impacto. Si botón, campo, aviso, diálogo, menú y tabla nacen accesibles, todos los equipos reutilizan una base mejor. Documenta nombre accesible, foco, teclado, contraste, errores y ejemplos.

Un componente conforme aún puede utilizarse mal. Añade patrones de composición para formularios, autenticación, tablas y navegación, además de reglas de contenido claro.

Ejemplo: reserva de un servicio

El recorrido incluye calendario, hora, dirección y confirmación. Se exige funcionamiento por teclado y lector de pantalla; el día seleccionado debe anunciarse; las horas no disponibles no dependen solo del color; los errores aparecen junto al campo y en un resumen.

Las pruebas automáticas detectan etiquetas ausentes, contraste y atributos inválidos. Una prueba de componente comprueba el foco del calendario. En la revisión manual, una persona con lector de pantalla descubre que el cambio de mes no se anuncia. La corrección se hace en el componente y protege otros productos.

Crea un pipeline de accesibilidad

  1. Lint durante el desarrollo: detecta patrones inválidos pronto.
  2. Pruebas de componentes: estados, nombres y teclado.
  3. Pruebas de recorrido: tareas críticas en navegador.
  4. Auditoría automática en CI: bloquea infracciones conocidas.
  5. Revisión manual: teclado, lector, zoom, voz y dispositivos reales.
  6. Pruebas con personas con discapacidad: encuentran barreras que una herramienta no interpreta.

W3C recuerda que ninguna herramienta determina por sí sola la conformidad. La automatización aporta velocidad y regresión; la evaluación humana interpreta uso, claridad e impacto.

Usa severidad, no una nota única

Una puntuación alta puede ocultar una barrera que impide pagar. Clasifica por impacto, alcance y alternativa. Un botón sin nombre en la confirmación puede ser bloqueante; una descripción demasiado larga, importante pero no impeditiva.

Define controles de release: cero bloqueadores en recorridos críticos, ninguna regresión en componentes compartidos y plan con responsable y fecha para limitaciones restantes.

Documenta con transparencia

Una declaración útil indica estándar, medidas, entornos probados, limitaciones y contacto. ACCESSIBILITY.md mantiene información cerca del código y facilita contribuciones, mientras la versión para usuarios se publica en la web o aplicación.

No prometas “100 % accesible” sin evidencias. Explica el estado, las alternativas y el proceso de respuesta. En España y la UE, determinados servicios y organismos tienen obligaciones concretas; revisa la normativa aplicable con asesoramiento especializado.

Lo que no soluciona el problema

  • instalar un overlay y dar el producto por corregido;
  • ejecutar un escáner solo antes del lanzamiento;
  • usar ARIA en lugar de HTML semántico;
  • asignar toda la responsabilidad a QA;
  • probar una pantalla e ignorar recorridos;
  • investigar sin incluir a personas con discapacidad;
  • publicar una declaración sin canal real de respuesta.

Plan para un producto existente

  1. Prioriza recorridos: ingresos, acceso, soporte y obligaciones.
  2. Haz inventario: componentes, plataformas, contenido y proveedores.
  3. Mide el baseline: automatización más revisión manual.
  4. Corrige en origen: sistema de diseño antes que páginas aisladas.
  5. Añade controles: evita que vuelvan fallos conocidos.
  6. Publica la declaración: límites, contacto y compromiso.
  7. Supervisa: feedback, métricas y auditorías periódicas.

Accesibilidad como calidad de producto

Las interfaces accesibles suelen ser más claras, robustas y fáciles de usar en distintos dispositivos. El beneficio supera el cumplimiento: mejora la experiencia, reduce soporte y amplía el público que completa tareas.

ProativaIA desarrolla aplicaciones, sistemas a medida y plataformas web. Podemos auditar recorridos, mejorar componentes, automatizar pruebas e incorporar accesibilidad al ciclo de entrega.

Referencias